RequiredArgsConstructor to include inherited required fields

[Thibault Nélis]

Hello,

I would like to suggest a discussion about a feature like this, as it'd
be very useful for some use-cases (at least I ran into one).

Just to be sure there's no ambiguity; I think there is value in making

abstract class C { final T v; }
@RequiredArgsConstructor class S extends C { }

generate a constructor having an argument to initialize variable "v" (in
addition to the other required fields) for subclass S.

The use-case I ran into is when trying to write a hierarchy of immutable
@Data classes. They can contain quite a few fields, and one must write
extremely similar *and trivial* constructors for each subclass.

It is trivial in the sense that they always do the same thing: call
super() for all inherited variables, and initialize other variables the
usual way, duplicating the work of @RequiredArgsConstructor.

The order of the arguments can be discussed, but I think they should
naturally go from base to sub class.

I've read the "Use of @Inherited for class-level annotations?"
thread[1], and I believe the approach and goals differ enough to justify
a new discussion.

Thanks for your work on Lombok, it's greatly appreciated. I would have
loved to come to you with proof-of-concept code, but these damn
schedules won't let me code it.

1:
https://groups.google.com/group/project-lombok/browse_thread/thread/bd5f8ba5f1d9369e/
--
t

[Robbert Jan Grootjans]

Let me see if I understand correctly, if a class with a requiredargs
annotation has an abstract superclass, we should create a constructor
that has all parameters necessary for the (let's asume singular)
superclass constructor. This would either require resolution or access
to the source material.

Getting the source of a related class is just not possible afaik.
Getting resolution to work for @Delegate and ' var' was is giving us a
lot of headaches and are the main reason we cannot release 0.10.0.
We're getting there, I'm just not getting warm to the idea of adding a
lot more resolution based features in the short notice. So, I think we
should go with resolution (if this feature is appealing enough to a
large audience),just not on the short notice.

> --
> You received this message because you are subscribed to the Google
> Groups group for http://projectlombok.org/
>
> To post to this group, send email to project...@googlegroups.com
> To unsubscribe from this group, send email to
> project-lombo...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/project-lombok?hl=en

[Thibault Nélis]

On 04/28/2011 01:09 PM, Robbert Jan Grootjans wrote:
> Let me see if I understand correctly, if a class with a requiredargs
> annotation has an abstract superclass, we should create a constructor
> that has all parameters necessary for the (let's asume singular)
> superclass constructor. This would either require resolution or access
> to the source material.

That's exactly it, yes. Actually, the base class doesn't have to be
abstract, I have no idea why my brain made me type this in my example.

> Getting the source of a related class is just not possible afaik.
> Getting resolution to work for @Delegate and ' var' was is giving us a
> lot of headaches and are the main reason we cannot release 0.10.0.
> We're getting there, I'm just not getting warm to the idea of adding a
> lot more resolution based features in the short notice. So, I think we
> should go with resolution (if this feature is appealing enough to a
> large audience),just not on the short notice.

Okay, I wasn't aware of this complexity. I must also admit that I don't
understand it perfectly at first sight; @EqualsAndHashCode and
@ToString can call super() with callSuper=true already, does the extra
step of getting the fields of the base class involve a whole other
challenge? (Please tell me if I'm way off.)
--
t

[Reinier Zwitserloot]

We don't know the source, or even the structure, of your parent. We just know you have one (because there's an 'extends' clause, and its not followed by (java.lang.)Object).

For equals and hashCode() we don't need to know anything about what your parent looks like, we know it has equals and hashCode methods and we know exactly how we should call them.

For calling the superconstructor, we don't - we need to know the types and # of parameters, and that requires knowing the source or structure of the parent. We can sort of do that, but that's what Robbert Jan was talking about: It's very complicated and we haven't quite sorted it out completely yet.