[records] Summary so far

[Remi Forax]

----- Mail original -----
> De: "Gavin Bierman" <gavin.bierman at oracle.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 18 Février 2020 16:19:48
> Objet: [records] Summary so far

> Dear Experts:
> 
> In [1] Brian asked for comments on some remaining design decisions concerning
> records (and asked for any new ones that you'd like to raise).
> 
> First, thank you for your feedback so far! I have been through the threads, and
> tried to summarize the question and the current status below. Of course,
> these decisions are not set in stone, but the point of this email is to warn you
> that they are hardening :-) So, if you disagree, or would like further
> discussion, *now* is the time to speak up!
> 
> 
> Q1. Should the distinguished supertype of records java.lang.Record be
> renamed?
> 
>    [Since the original post, it seems that inline types will be able to inherit
>    from abstract classes.]
> 
>    Is the name "Record" a good one? It has good clash
>    potential :-) possible alternatives are RecordClass, or AbstractRecord?
> 
>    A: No consensus so far.

Given that Enum is not AbstractEnum so I'm ok with java.lang.Record

> 
> Q2. Accessibilty of mandated members.
> 
>    Currently the mandated members are public regardless of the accessibility of
>    the record type. What should be the default accessibility for record
>    members?
> 
>    A: Currently the most popular proposal is that mandated members get
>    accessibility of the record type. Other members get package level
>    accessibility as per a regular class. (Note: it should be legal for explicit
>    declarations of mandated members to specify something _more_ accessible
>    (same rules as overriding.) )

+1

> 
> Q3. Nesting.
> 
>    A: We are working on a new spec that removes a lot of restriction regarding
>    nested classes/records.

+1

> 
> Q4. Abstract records.
> 
>    Should we allow the declaration of abstract classes, possibly supporting
>    some form of record subtyping?
> 
>    A: No support for this.


I agree, no support.

> 
> Q5. Deconstruction patterns.
> 
>    A: We will be proposing deconstruction patterns in the patterns v2 preview.


This one worry me because we are proposing deconstruction patterns without introducing deconstruction patterns for declaring local variable at the same time.
so
  p instanceof Point(var x, var y)
is ok but
  Point(var x, var y) = p;
is not.

I understand that in term of JEP adding deconstruction patterns in the patterns to the JEP seems to be a small refinement but
- i would like to be sure that the same syntax can be used for local variables declaration, do you have a grammar issue here ?
- i don't want to see people abusing of instanceof has a destructuring construct because we don't propose a destructuring one at the same time.
  

> 
> Q6. @deprecated
> 
>    Should we allow record components to be marked as @deprecated?
> 
>    A: We don't want to add any additional support for @deprecated beyond the
>    fact that it is an annotation and it can be inspected via reflection.

Fine, this as been settled (at least for me).

> 
> Q7. .equals and .toString are slow.
> 
>    Remi [2] points out that the current implementations of .equals and
>    .toString are slow.
> 
>    A: We will look into this.


.equals() and .hashCode() are not slow, .toString() is slow :)

> 
> Q8. Translation strategy.
> 
>    John [3] suggested changing the compilation strategy of records so we can
>    future-proof the evolution of members from the record supertype.
> 
>    A: No change.


Q8 and a half,
  I've sent my own proposal to slightly change the compilation strategy of the Object methods to use reflection on the Record attribute instead of asking to send constant method handles.

> 
> Q9. Hashing.
> 
>    John [4] proposed weakening of the .hashCode spec.
> 
>    A: Agreed. John has written candidate text [5].

I agree

> 
> Q10. Special annotation for explicit declaration of accessors.
> 
>    Tagir [6] proposes a new `@RecordAccessor` annotation to mark explicit
>    accessors, much as `@Override` is used to mark method overrides.
> 
>    A: Rather than introduce a new accessor, we will consider extending the
>    meaning of the `@Override` annotation to include this case.


I agree, @Override is fine here even if it's not a real override (using @Override on an asbtract method of an interface is not a real override too so @Override doesn't mean @Override since Java 6 anyway).

> 
> Q11. Changing the spec of .toString method
> 
>    We should weaken the spec of the .toString method so it explicitly states
>    that the form of the string produced is subject to change and can not be
>    relied upon.
> 
>    A: Agreed.

I agree.

> 
> Q12. Transactional methods
> 
>    Canonical constructors are an instance of a general pattern where a set of
>    variables are in scope for a given block, and assigned values at the end.
>    This could be a useful abstraction to be given first-class representation.
> 
>    A: No change. More research needed.


yes !

> 
> Q13. Factory methods instead of constructors.
> 
>    Should "new R(v1, ..., vn)" be compiled to a factory method, to allow
>    future-proofing with inline types?
> 
>    A: No change for now.

yes !

> 
> Thanks for your comments and discussions so far. If you disagree with anything
> written here, please reply!
> 
> Thanks,
> Gavin

Rémi

> 
> 
> [1]
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001913.html
> [2]
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001943.html
> [3]
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001937.html
> [4]
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001935.html
> [5] http://cr.openjdk.java.net/~jrose/draft/record-contract
> [6]
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001931.html