Thank you both. So the answer boils down to, not enough realized value for the effort involved. More specifically, it may foreclose on other things while not really giving us much at all. Makes sense, and that's fair.
On Tue, Sep 23, 2025, 8:31 AM Remi Forax <[email protected]> wrote: ------------------------------ *From: *"David Alayachew" <[email protected]> *To: *"valhalla-dev" <[email protected]> *Sent: *Tuesday, September 23, 2025 2:19:40 PM *Subject: *Question about Value Classes and inheritance Hello @valhalla-dev <[email protected]>, I read through JEP 401, and the subsection about subtyping surprised me. It appears that Abstract Value Classes can permit both Value child classes and Identity child classes. The example of BigInteger helps explain why. Ok, but there doesn't seem to be any way to say "only value classes can extend me!" Why is that? And to be clear, I am not bothered by Abstract Value Classes permitting Identity children, that's fine. I'm glad this is fine by you because it's important for backward compatibility, it means that you can declare an existing abstract class has "value enable", without requiring sub-classes to be changed. I'm moreso confused by lack of ability to say "only value children". Declaring a class has a value class is really close to be an implementation detail (it mainly depends on if your code abuse of == or not), so why do you want such ability ? Thank you for your time and consideration. David Alayachew regards, Rémi On Tue, Sep 23, 2025, 9:33 AM Brian Goetz <[email protected]> wrote: > Ok, but there doesn't seem to be any way to say "only value classes can > extend me!” > > > At some level, this is a matter of taste and return-on-complexity. > Obviously this is not _needed_, but some programmers are clearly comforted > by the ability to capture this intent. Of course, adding such restriction > adds complexity at every layer; it needs a syntactic expression, it needs a > clasfile representation, it needs static type checking, it needs dynamic > enforcement, it needs reflection, etc. So the first question is: does the > incremental expressiveness justify the incremental complexity? > > But more importantly, as Remi points out, seemingly harmless “intent > capturing” things at the source level can turn into unexpected difficulties > for longer term issues such as migration compatibility. We saw a similar > example of this in Java 8, where people asked “why can’t I make a default > method final”, but then when you show them the impossible problems this > creates for subclasses, they change the subject. Foreclosing on > possibilities like this, that are often “over the maintenance horizon”, are > often “shallowly sensible” but make the ecosystem brittle. > >
