Value types design decisions

[Brian Goetz]

This interacts with nullity control.  If a variable is nullable, its 
default value is null -- end of story.  But nullability is often (not 
always) an impediment to flattening.  So if you want a flat field / 
array, you probably are using a non-nullable field/component type.  Of 
the three kinds (identity (String), implicitly constructible value 
(Integer), non-implicitly-constructible value (LocalDate)), we get three 
different stories about flattening and failure modes:

String![] -- these will never be flattened, so the default value of 
elements is still null.  We have some design choices about whether to 
make "good faith efforts" for preventing these from being published 
before being fully ininitialized, but if one does escape, the downside 
is not terrible -- an unexpected NPE, but no loss of integrity.

Integer![] -- these can get flattened routinely, and it's perfectly fine 
to publish an array whose elements are uninitialized, because Integer is 
implicitly constructible, which means the default value is just fine.

LocalDate![] -- We can flatten these only if we have 100% ironclad proof 
that every element has been initialized to a valid value prior to 
publication.  Allowing the zero to escape undermines a VM integrity 
promise, and this can never happen.

As to "how would this work", design discussions are ongoing, stay tuned.


On 1/20/2024 2:41 PM, David Alayachew wrote:
> Hello Brian,
>
> Just wanted to ask about this point below.
>
> > These two examples (conveniently, from the same package)
> > tell us a truth about modeling data with value objects:
> > some classes have reasonable defaults (and we can exploit
> > this to optimize their treatment, and can freely let
> > people use uninitialized variables, as we do for
> > primitives today), and some do not (and hence we need
> > either to engage nullability, or work very hard to ensure
> > that an object cannot possibly be used uninitialized.
>
> Oh woah, what does it look like to prevent an object to be used 
> uninitialized? We don't have any compiler-enforced ways of doing this, 
> right? You are talking about just manually code reviewing each use of 
> the class to try and hope to catch any misuse?
>
> And if you mean manual review, is that really something that would be 
> worth the effort? Aside from the most trivial situations, I can't 
> think of an example.
>
> Thank you for your time and help!
> David Alayachew
>
> On Sat, Jan 20, 2024 at 2:23 PM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>     Forgot to address this part.
>
>     On 1/20/2024 2:00 AM, Smith Wilson wrote:
>     > It could solve problems with such classes like LocalDate which
>     require
>     > more special zeroInstance (1970-1-1) than value with pure defaults.
>
>     The key thing to realize about LocalDate is that while it is a good
>     candidate for being a value type, there is *literally no* good
>     default
>     value.  Jan 1 1970 is not a good default value, as we've all seen by
>     getting emails that tell us our subscriptions are going to expire 54
>     years ago.  No other specific date is a good default either. This
>     is a
>     statement about the _domain_; there is no good default.  (And when an
>     abstraction does not have a good default, null is your friend.)
>
>     Other classes have good defaults; Duration is such an example.
>
>     These two examples (conveniently, from the same package) tell us a
>     truth
>     about modeling data with value objects: some classes have reasonable
>     defaults (and we can exploit this to optimize their treatment, and
>     can
>     freely let people use uninitialized variables, as we do for
>     primitives
>     today), and some do not (and hence we need either to engage
>     nullability,
>     or work very hard to ensure that an object cannot possibly be used
>     uninitialized.
>
>     The reason that "implicit constructor" is a thing is that, even after
>     we've identified that a class is a value class, we still have to
>     identify something else: whether it is implicitly constructible or
>     requires explicit construction.  (There's other ways to frame it, of
>     course, but the key is that this has to be in the programming model.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240120/676b21d3/attachment.htm>