value type hygiene

[Brian Goetz]

Please, no.  


Sent from my iPad

> On May 15, 2018, at 8:43 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
>> On May 15, 2018, at 5:17 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>> 
>>> On May 15, 2018, at 4:53 PM, John Rose <john.r.rose at oracle.com> wrote:
>>> 
>>> If we can implement EVBCs easily as a one-off from full value type,
>>> in the context of L-world, should we try it?  People responsible for
>>> user model (hi Brian!) might say "yuck, we are admitting design
>>> failure by giving a consolation prize to the VBCs, instead of the
>>> real VTs promised".  Maybe EVBCs are the best engineering
>>> compromise, or maybe we just cut EVBCs off the feature list
>>> and say "VT or VT not", at which point people who wrote VBCs
>>> will have sad decisions to make, and Dan will tell them not to
>>> migrate at all.
>> 
>> Yeah, I'm pretty down on the benefit of these half-value classes. We'd be better off deprecating the old API classes and introducing new, "real" value class versions.
> 
> OK, good; that's one less vote for a special JVM feature just for
> migration.
> 
> Doing things that way could look like this:
> 1. rename LocalDateTime to LocalDateTimeVT (not its real name)
> 2. make LocalDateTimeVT be a value type
> 3. reconstruct the API of LocalDateTime, this time as an Integer-like wrapper for LocalDateTimeVT
> 
> BTW, this raises a bee which was sleeping in my bonnet:
> This is a good time to reconsider the rules for capitalizing types.
> 
> Right now, at this special moment in time, all value types have
> lower-case names, and all object type names begin with an
> upper-case letter.  This is trivially true because only primitives
> are value types, and we followed the C tradition of naming them.
> 
> So, how about we keep this useful state of affairs?  Let's declare
> that value types will conventionally be camel-case names with
> an initial lower-case letter.
> 
> At that point, the migrated LocalDateTime gets an obvious
> and memorable name, localDateTime.  (Perhaps, to avoid
> collisions with method names, we might perturb the convention
> a little more, but I don't think it's needed.)  I think that would be
> a useful outcome.
> 
>> The great thing about use site expressiveness is that different clients can choose different trade-offs, rather than forcing a single choice on all clients.
> 
> We can use ValueRef<VT> vs VT, with language sugar or without,
> to provide the most common kinds of use-site expressiveness.
> 
>> The one declaration-site strategy I could see being viable is (per Maurizio, above) to allow a value class to assert that its default value should be treated as null, with all associated semantics (ifnull, NPE checks).
> 
> As noted before, that's doable, but there are details to work out.
> 
>> Then your safe migration path for VBCs is to design a field layout that has an acceptable 'null' encoding—often no sacrifice at all.
> 
> Yes; all nulls get funneled to the naDT value of LocalDateTime.
> That's not terrible, but needs work to flesh out.
> 
> — John