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
