@Data should default to callSuper=true

[Jacek Furmankiewicz]

So far every single time I use @Data on a class that extends an
ancestor I have to manually add @EqualsAndHashCode
(callSuper=true)....and then @ToString(callSuper=true)

I think the default behavior of @Data is incorrect. it should default
to callSuper=true across the board (the more likely scenario) and
allow overriding to use callSuper=false if someone really needs it
(the less likely scenario).

I am building a complex JPA entity model with 2-3 layers of
inheritance in some places and I wish @Data would handle
callSuper=true by default....

What do you think?

[Roel Spilker]

We will extend @Data to support the callSuper parameter. However,
making it the default is not the best solution for most data classes,
as the are a direct subclass of Object, and the you definately do not
want to call the super. We will investigate sensible defaults
depending on the superclass, but for that to work we need to have more
information on the actual superclass, and currently for Eclipse that
is not possible.

I see you already found http://code.google.com/p/projectlombok/issues/detail?id=19

Roel

[Jacek Furmankiewicz]

I think that is acceptable too, I see your point on not defaulting it
for direct ancestors of Object.

Although we could probably make it to by default the most logical
thing, i.e. do not call super if extends Object, call super if extends
anything else.

That default rule would be most logical, cover probably 99% of cases,
but you could still have an explicit callSuper in there if you want to
override the default behavior.

Cheers, Jacek

[Reinier Zwitserloot]

No, you can't just call super. It's just too complicated.

There are two situations (beyond extending Object directly) for which
calling super is no good, and it's not possible for lombok to tell. It
can only be sure when the superclass has lombok-generated equals and
hashCode memories, and we'd have to modify equals and hashCode to add
an annotation so lombok can tell even when you're extending classes
that aren't available in source form. In other words, rather
complicated stuff, for not a whole lot of gain. The situations are:

1) The superclass has no equals/hashCode implementation whatsoever.
This can be quite common, especially for flag-like superclasses that
don't themselves have any fields.

2) The superclass has an equals implementation that is extending-
capable. For example, if you class-check via: "if ( o.getClass() !=
MyClassName.class ) return false;" which I've seen here and there,
calling super is _definitely_ the wrong thing to do.

[Michael Lorton]

Out of curiosity: what is so bad about calling the Object constructor?  It seems like it should do nothing at all.

M.

[Reinier Zwitserloot]

This is about calling Object's implementation of hashCode() and equals
(), which are both 'broken'.

On Aug 31, 10:25 pm, Michael Lorton <mich...@circuspop.com> wrote:
> Out of curiosity: what is so bad about calling the Object constructor?  It
> seems like it should do nothing at all.
>
> M.
>