Please, no.
Sent from my iPad > On May 15, 2018, at 8:43 PM, John Rose <[email protected]> wrote: > >> On May 15, 2018, at 5:17 PM, Dan Smith <[email protected]> wrote: >> >>> On May 15, 2018, at 4:53 PM, John Rose <[email protected]> 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
