Simplifying 'value' and 'identity'

John Rose john.r.rose at oracle.com
Tue Feb 13 21:38:51 UTC 2024


Good summary, Kevin.  And, regardless of your email domain, please do 
keep your chair at this table!

I think one smallish reason we had more value-related distinctions in 
the past, among supers, was our inability to imagine how abstract 
classes might contribute constructors and fields to values.  We have a 
story for that now, but only since last July (at the earliest).  Now, 
more super classes are value-capable, so there is less need to mark them 
explicitly value-capable, and then to check them structurally against 
such markings.  No marks are the best marks.

On 8 Feb 2024, at 18:32, Kevin Bourrillion wrote:

> Hey everyone,
>
> [I assume Google will put forth a replacement representative at some 
> point,
> but either way I've joined this group as an individual member.
> kevinb9n at gmail.com is how to reach me now!]
>
> Here's a response to Dan's December thread
> <https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-December/002402.html>
> which I can't reply to from this other account.
>
> So as far as I can tell I think this dovetails perfectly with what 
> I've
> always wanted, which is the "identity is just an attribute" model. I 
> like
> pretty much everything about it. Under that idea, identity is absent 
> at the
> root of the hierarchy, can be added by any subtype, then is inherited 
> by
> everything below that. Any type that wants to be mutable, lockable, 
> etc.
> would have to flip that identity switch on.
>
> So I don't see that there needs to be any difference between "value" 
> and
> "indeterminate". Both are just "doesn't have the identity attribute".
>
> I feel like there must have been some reason we thought that wouldn't 
> pan
> out, but I don't remember. In some sense, adding the "attribute" of
> identity also *removes* a capability at the same time (the capability 
> of
> being copyable and collapsible at the VM's whims), and at one point I
> thought that sunk the whole model. But that's not a *client*-facing
> capability, and I think maybe that excuses it.
>
> So anyway, I *think* the only adjustment to my preferred dream model 
> that I
> recognize in Dan's email is "interfaces don't get to add this identity
> attribute", which okay, no great loss I suppose.
>
> Of course, I don't remember what past discussions I don't remember, so
> please let me know what I'm missing here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20240213/7f4cdd5f/attachment-0001.htm>


More information about the valhalla-spec-observers mailing list