Abstract record

[Remi Forax]

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.goetz at oracle.com>
> À: "amber-spec-experts" <amber-spec-experts at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200109/8ccda326/attachment.htm>