On 09/10/2019 19:34, Remi Forax wrote:

----- Mail original -----
De: "Remi Forax" <fo...@univ-mlv.fr>
À: "Brian Goetz" <brian.go...@oracle.com>
Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
Envoyé: Mercredi 9 Octobre 2019 18:44:23
Objet: Re: Record Component attributes
----- Mail original -----
De: "Brian Goetz" <brian.go...@oracle.com>
À: "Remi Forax" <fo...@univ-mlv.fr>, "amber-spec-experts"
<amber-spec-experts@openjdk.java.net>
Envoyé: Mercredi 9 Octobre 2019 17:59:56
Objet: Re: Record Component attributes
just to be sure, do we agree that a record component can be deprecated,
synthetic, have a generic signature, have unknown attributes, have annotation
and type annotations ?
Deprecated: not clear what this would mean, since removing a component
is not a BC or SC change, and therefore removal seems unlikely, but I
suppose deprecation could be a "stay away" warning sign for that
component?  On the fence.

Synthetic: I think this is a no.  The philosophy is: a record is a class
whose representation and API are both derived from the state
description.  Having a synthetic component would be weird (same reason
we don't have inner records.)

Generic signature: yes, definitely.

Unknown attributes: I believe that Dan had an opinion here, as reflected
in the current spec draft?

Declaration and type annotations: yes, definitely.
given it's the class format representation, i will wear my JVM runtime
implementer hat :

There a lot of languages that have default value for parameters, so for
constructor parameters,
for those it makes sense to be able to deprecate a record component if at the
same time you provide a default value for this component.

for synthetic, a synthetic component is a component that the VM (or the
reflection) sees but that javac doesn't see. Reified generics stored as
parameter like in Swift is a case where you may not want javac to see your ugly
refiied type/witness type/etc.
and answering to myself,
javac doesn't directly access to the record component, it accesses to the 
generated fields/methods so making the record component synthetic or not has no 
impact on javac, so marking a record component Synthetic seems useless.

I think the problem of this question is not whether it would make sense for Java right now, but whether it could make sense for other languages (or even Java of tomorrow) to use records as a translation target; now, this seems not super likely given that records are a restriction of a more general construct (class), so a compiler would probably prefer the more general target.

Synthetic can be useful in situations where there are 'hidden' components that are injected by javac, pretty much as a hidden this$0 is added on all inner classes. It's there, but you are not allowed to see it (or match on it), not from the language, not from core reflection. Right now we don't envisage any purpose for doing something like this, but I also don't immediately see a reason for shutting down the door on it either. Perhaps this _hidden_ nature of synthetic components could be used as a motivation as to why we don't like ACC_SYNTHETIC to be added in the mix - on the one hand we're saying "records are all about transparent state", and, with synthetic components, this goes down the drain a bit, as there are hidden parts of the state you can't see or pattern match.

As for DEPRECATED, it doesn't make a lot of sense, but not sure whether source/binary compatibility is a good explanation; after all, removing a class field is neither BC nor SC (for clients that refer to that field). The problem with records is just made worse by the fact that, with pattern matching and, deconstructor patterns we envision that 'accessing all components' will be a routine operation. But it's a quantitative change, not a qualitative one, IMHO.

Maurizio


Rémi

so the attributes with a special meaning are
    SIGNATURE, DEPRECATED, SYNTHETIC, RUNTIME_VISIBLE_ANNOTATIONS,
    RUNTIME_VISIBLE_TYPE_ANNOTATIONS, RUNTIME_INVISIBLE_ANNOTATIONS and
    RUNTIME_INVISIBLE_TYPE_ANNOTATIONS.

said differently, it's all the attributes allowed on a field but CONSTANTVALUE
which makes no sense on a record component.

regards,
Rémi

Reply via email to