value type hygiene

[John Rose]

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