On Mon, Oct 4, 2021 at 5:04 PM Dan Smith <daniel.sm...@oracle.com> wrote:
and because I want to encourage focusing on the contents of the original > mail, with this reply as a supplement. > Noted, but didn't have much useful to reply. I definitely think this is the right problem to be solving... A "classic" and "encapsulated" pair of clusters seems potentially workable > (better names TBD). Tend to agree. > Nullability can be handled in one of two ways: > > - Flush the previous mental model that null is inherently a reference > concept. Null is a part of the value set of both encapsulated primitive > value types and reference types. > imho there are other arguments for striking "the null reference" in favor of "the null value". A reference ought to be something you can *de*reference. And, it isn't really reference types *themselves* that bring null into the picture; it's the way Java "grafts" the null type onto most *usages* of a reference type. I do think many people will experience initial shock/aversion at this, owing primarily to decades of hating null. But it shouldn't be hard for them to recognize that however bad null might seem, a false value is worse, and that fact has nothing to do with references. For migration, encapsulated primitive classes mostly subsume > "reference-default" classes, and let us drop the 'Foo.val' feature. Indeed, it would probably be bad to introduce the classic/encapsulated distinction if it *can't* fully get rid of the val-default/ref-default distinction. > For the "encapsulated"/"classic" choice, perhaps "encapsulated" should be > the default. Classic primitives have sharper edges, especially for class > authors, so perhaps can be pitched as an "advanced" feature, with an extra > modifier signaling this fact. (Everybody uses 'int', but most people don't > need to concern themselves with declaring 'int'.) > fwiw, I agree (strongly). Atomicity: > > Alternatively, can we train programmers to treat out-of-sync values with > the same tolerance they give to out-of-sync object state in classes that > aren't thread safe? It seems bad that a hostile or careless third party > could create a LocalDate for February 31 via concurrent read-writes, with > undefined subsequent instance method behavior; but is this more bad than > how the same third party could *mutate* (via validating setters) a similar > identity object with non-final fields to represent February 31? > That seems reasonable. > If, pessimistically, the overall performance doesn't look good, it's worth > asking whether we should tackle these use cases at all. But there's a risk > that developers would misuse classic primitives if we don't provide the > safer alternative. Could we effectively communicate "you're doing it wrong, > just use identity"? Not sure. > It may be over-idealistic of me, but I think the less people have to make new identity objects when they didn't care about identity *per se*, the better. -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
