Still on my to-do list:
- @Deprecated on record components
- change the bootstrap method protocol (a little bit)
- equals/hashCode implementation are currently slooooow
- the bytecode representation can be more lightweight
- separate the bootstrap entry point used by Java from the one that can be used
by other JVM languages
so the Java bootstrap entry point can use the RecordComponent attribute without
mandating this attribute to
be present if another language just want an implementation of
equals/hashCode/toString to be provided by the JDK.
and as you already mentioned it, the visibility of members.
Rémi
De: "Brian Goetz" <brian.go...@oracle.com>
À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
Envoyé: Jeudi 9 Janvier 2020 00:55:10
Objet: [records] Record updates for Preview/2
BQ_BEGIN
We're gathering a list of what non-bugfix things we want to do for the second
preview of records. So far, on my list, I have:
1. Revisiting the j.l.Record supertype. We want to support inline records when
we have inline types. Until now, we've been working on the assumption in
Valhalla that inline classes can only extend interfaces, not abstract classes,
so it was suggested that Record should be an interface. However, that topic in
Valhalla is under reconsideration, and I want to wait until that discussion
plays out before making any changes here.
It has also been pointed out that the name Record is somewhat clash-y. I'm not
really willing to pick a lousy name just to reduce the chance of clashes, but I
might be OK with a name like RecordClass. (Bikeshed alert: if you want to
discuss any of these topics, please start a new thread; this one is about
curating a to-do list.)
2. Accessibility of mandated members. Remi noted that the requirement that the
mandated record members be public, even for non-public classes, was weird. But,
at the time, the spec was in a state that trying to revisit this was
impractical -- Gavin has now left the spec in a much cleaner place, and so it
is reasonable to reopen this discussion. The leading alternate candidate is to
propagate the accessibility of the record to its mandated members (public for
public, etc), but still require the author to say what they mean.
3. Nesting considerations. In 14 we will fix the issues surrounding local
records, but we still ban nested records in non-static classes. We should fix
this -- by dropping the restriction on static members in inner classes -- and
then bring records, enums, and interfaces to parity (allowing local and nested
flavors of all, all implicitly static.)
4. Abstract records. Several people have asked "what about abstract records";
while these are theoretically possible, there are some complications that I
think are best left for treating these as a later addition if needed. But, for
the record, here are some thoughts from the last time I looked into this.
Given that records are nominal tuples, the notion of "width subtyping" comes
immediately to mind. So, let's go with that for a moment: you could say
abstract record A(int a, int b) { }
and
record B(int a, int b, int c) extends A { }
and there is a natural width subtyping relationship. We don't have problems
with the equality contract because the abstract class leaves equals() abstract.
But, this is a story that is likely to not be entirely satisfactory. Do we
require that the state of A form a prefix for the state of B? This may not be
the API people want. Do we require that super(a,b) be passed through unchanged?
The constraints on the subclass in this model get, constraining.
What if there were a more flexible relationship:
record B(int a, int b, int c) extends A(a, b) { }
Now, there's more flexibility, at the cost of a new "extends" construct. And
what if you want to fix some field of A as a constant:
record iload2_bytecode() extends bytecode(0x1c) { }
These all seems like reasonable things to want when you get into abstract
records ... but they all start to push on the "records imperative". So for now,
we're doing nothing, until we have a better story for what we actually want to
do.
5. Deconstruction patterns. Yes, records should be deconstructible with
deconstruction patterns.
Anything else, that we've already discussed that I left out?
BQ_END
