[External] : Re: Consolidating the user model

[Brian Goetz]

> My concern is that the purest form of value types will be overused and 
> misused for even less clear-cut cases. I would like to think that we 
> can convince these users that they really want the next "bucket" over, 
> which I think comes down to whether the added cost of `null` is worth it.

I share this concern.  Do you have any thoughts of how to make B2 more 
attractive?

For the record, we expect to see similar stack-based and IR-based 
flattening across buckets 2 and 3, but measurably less heap-based 
flattening for bucket 2.  Plus the extra footprint.

> Btw, am I right that for the middle bucket, `==` will fail (at 
> compile-time when possible)?

B2 gets state-based ==, just like B3.  No difference there; if you have 
no identity, then equality is state-based.

>
>
>     The third bucket are the _true primitives_.  These are also
>     identity-free
>     classes, but further give rise to both value and reference types,
>     and the value
>     type is the default (we denote the reference type with the
>     familiar `.ref`.)
>     Value types are non-nullable, and permit tearing just as existing
>     primitives do.
>     The `.ref` type has all the affordances of reference types --
>     nullability and
>     tearing protection.
>
>
> In fact, if I'm looking at a middle-bucket class, and I'm looking at 
> one of these `.ref` types of "primitive" class, as far as I can tell I 
> should be able to think of these in exactly the same way as exactly 
> the same things.

Yes.  A B2, and a B3.ref, behave identically.

> (I'm aware you intend to define `==` differently for the two, but I'll 
> get into my massive concerns about that later.)

Actually, B2, B3, and B3.ref all have the same interpretation of ==, 
which is state-based.  (You can think of this as "box (or unbox) before 
comparing a B3 with a B3.ref.)

>
>      - Null-adjunction.  Some methods, like `Map::get`, return null to
>     indicate no
>        mapping was present.  But if in `Map<K,V>`, `V` is not
>     nullable, then  there
>        is no way to express this method.  We envision that such
>     methods would return
>        `V.ref`, so that strict value-based classes would widened to
>     their "box" on
>        return, and null would indicate no mapping present.
>
>
> Now just spell it `?` :-)
> (not serious. Also, not not serious)

Yeah, maybe.  If that were the only difference, I'd be more inclined.  
But it drags in ref-ness, and all the reference affordances, so it feels 
more misleading than helpful at this point.

>
>     ## Reflection
>
>     Earlier designs all included some non-intuitive behavior around
>     reflection.
>     What we'd like to do is align the user-visible types with
>     reflection literals
>     with descriptors, following the invariant that
>
>          new X().getClass() == X.class
>
>
> Seems like part of the goal would be making it fit naturally with the 
> current int/Integer relationship (of course, `42.getClass()` is 
> uncommitted to any precedent).

There's a nasty tension here.  On the one hand, for B3 classes, it makes 
sense for b3.getClass() to yield the val mirror, but int.getClass() 
historically corresponds to the ref mirror (Object o = 3; o.getClass() 
== Integer.class.)  To invert it, we would have to break a lot of 
reflection-using code that tests for Integer.class because that's how 
primitives are reflected.  Work in progress.


> Actually, that makes me start to wonder if `getClass()` should be 
> another method like `notify` that simply doesn't make sense to call on 
> value types. (But we still need the two distinct Class instances per 
> class anyway.)

You could argue that it doesn't make sense on the values, but surely it 
makes sense on their boxes.  But its a thin argument, since classes 
extend Object, and we want to treat values as objects (without appealing 
to boxing) for purposes of invoking methods, accessing fields, etc.  So 
getClass() shouldn't be different.