callSuper option on @Data

[lombok]

Would it be possible to add a callSuper parameter to @Data.

I currently find myself adding both a @ToString(callSuper = true) and @EqualsAndHashCode(callSuper = true) to my objects which are annotated by @Data and extend another object.

Kind regards,
Joachim

[Reinier Zwitserloot]

The reason we're kinda holding off on that is that we want to eventually figure this out automatically with resolution.

Anyone else think it's a good idea to add to @Data?

[Marco Servetto]

I'm having trouble to use Data/Value with classes that extends stuff....
I'm not super fresh of memory, but I think is because the generated
constructor try to call
super() without arguments, and.... I understand is hard to do differently..
may be there could be a nice point in the middle?
can I specify how to call super? like
Data("super(Int a, Float b,MyFoo c)")
will call super using those parameters and also make data aware that
there is a super to call for toString etc..

> --
> You received this message because you are subscribed to the Google Groups
> "Project Lombok" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to project-lombo...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[lombok]

Obviously resolution would be even better. Is that difficult to add?

Kind regards,
Joachim

[Martin Grajcar]

On Mon, Jul 10, 2017 at 11:25 PM, Marco Servetto <marco.s...@gmail.com> wrote:

I'm having trouble to use Data/Value with classes that extends stuff....
I'm not super fresh of memory, but I think is because the generated
constructor try to call
super() without arguments, and.... I understand is hard to do differently..
may be there could be a nice point in the middle?
can I specify how to call super? like
Data("super(Int a, Float b,MyFoo c)")

That's ugly like hell, but I'm afraid, it's the only solution. So it's actually beautiful.

It's a hack and it's needed for multiple annotations, so I'd suggest something like

@HackSuper("int a, Float b, MyFoo c")

i.e., a separate annotation telling lombok that there's a super constructor to be called like this.

One day, when resolution works, you drop this annotation and are done.

While @Data mostly works with inheritance, @Value, @Wither and @Builder are rather unusable.

 

 will call super using those parameters and also make data aware that
there is a super to call for toString etc..

But should it work like @ToString(callSuper=true) or should it simply flatten the output by treating super fields as own ones (using getters)?

Would @ToString(flattenSuper=true) make sense?

[Reinier Zwitserloot]

@Value makes classes final, so unless here are hordes of folks putting @NonFinal on there to counteract that, it's not particularly common.

It's.. a hack. Probably the best way to do it, but, still.

[Marco Servetto]

>@Value makes classes final
Yes, but the inheritance here is in the opposite direction:
I have some (abstract) class that I want to use to generate a range of
Data/Value (especially Data) classes.
Does it looks like bad programming to someone here? I'm not really sure.

[Martin Grajcar]

On Wed, Aug 30, 2017 at 11:27 PM, Marco Servetto <marco.s...@gmail.com> wrote:

>@Value makes classes final
Yes, but the inheritance here is in the opposite direction:
I have some (abstract) class that I want to use to generate a range of
Data/Value (especially Data) classes.
Does it looks like bad programming to someone here? I'm not really sure.

To me, it looks good, at least before you more details.

I hardly ever use @Value, but most of my classes are immutable, anyway. Using Lombok makes me avoid inheritance from classes needing an non-trivial constructor, which sometimes leads to strange decisions. My most common usage is @RequiredArgsConstructor(onConstructor=@__(@Inject)) and sometimes, there are multiple such classes with some common functionality. If I'd extracted it to a superclass in the usual way, there would be final fields there and I'd have to write my constructor manually. So I do strange things like defining the fields in every child and providing getters for use in the superclass. At other times I avoid inheritance instead.

@HackSuper would really help. It'd be even better, when the IDE could add it automatically, when there's exactly one suitable super constructor.