abstract record is a big NO for me:
- we already discussed about that and perhaps it should be in the JEP but
because it's so easy to add a new record component to a record and the fact
that we have default method in interfaces,
there is no need of an abstract record.
- it also means that you can inherits record components, so the reflection API
has to be reworked to make the difference between the declared record
components and the inherited ones.
- and the concept of inheritance hierarchy is so overrated.
The code is hard to read, hard to impossible to refactor.
- extends + constant, it's reinventing the constructor initialization list of
C++ with all its problems.
and ironically, the value 0x1c will not be seen as a constant by the VM. So all
the drawbacks of the C++ notation, no advantage.
regards,
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
> 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?
