On 1/4/2020 10:35 AM, Tagir Valeev wrote:
Hello!
I was watching a Twitch stream by Nicolai Parlog [1] who explored the
records feature. Quite expectedly he did this reading JEP 359, rather
than the spec draft. He noticed at least two inconsistencies:
1. The record's body may declare static methods, static fields, static
initializers, constructors, instance methods, instance initializers,
and nested types.
"intance initializers" part should be removed, to match the spec draft.
Done.
2. Any of the members that are automatically derived from the state
description can also be declared explicitly.
private final fields that match the record components are members and
derived from the state description, so from this statement, one could
conclude that explicit field declaration is also possible (which is
not an unreasonable thing to do: one may want to customize the field
annotations). If we don't allow such a declaration, this statement
should be refined (probably changing 'members' to 'methods and
constructor' or 'members except field' or something like this).
This is a fair question; do we want to allow this? There are several
reasons one might want to do so:
- Consistency (though this is generally the reason you give when you
have no other reason), you can do it for the other members;
- Maybe the author wants the fields public;
- Maybe the author wants annnotations on the fields that, were they to
be put on the components, would be spread to places where they are _not_
wanted.
The last of these is the only one that is mildly compelling here, but, I
wonder whether this is purely theoretical, or whether someone actually
needs this.
The reasons against include:
- It is not likely to be something people want to do very often, and
so the return on spec complexity here is probably negative.
