<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">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:<br>
<br>
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. <br>
<br>
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. <br>
<br>
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.<br>
<br>
As to "how would this work", design discussions are ongoing, stay
tuned.<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 1/20/2024 2:41 PM, David Alayachew
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA9v-_OmpJRATp_obEK2D2YNDAoTgiWuNarWdD31hhDE9fagEw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-family:monospace">Hello
Brian,</div>
<div class="gmail_default" style="font-family:monospace"><br>
</div>
<div class="gmail_default" style="font-family:monospace">Just
wanted to ask about this point below.</div>
<div class="gmail_default" style="font-family:monospace"><br>
</div>
<div class="gmail_default" style="font-family:monospace">>
These two examples (conveniently, from the same package)<br>
> tell us a truth about modeling data with value objects:<br>
> some classes have reasonable defaults (and we can exploit<br>
> this to optimize their treatment, and can freely let<br>
> people use uninitialized variables, as we do for<br>
> primitives today), and some do not (and hence we need<br>
> either to engage nullability, or work very hard to ensure<br>
> that an object cannot possibly be used uninitialized.<br>
<br>
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?</div>
<div class="gmail_default" style="font-family:monospace"><br>
</div>
<div class="gmail_default" style="font-family:monospace">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.</div>
<div class="gmail_default" style="font-family:monospace"><br>
</div>
<div class="gmail_default" style="font-family:monospace">Thank
you for your time and help!</div>
<div class="gmail_default" style="font-family:monospace">David
Alayachew<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Jan 20, 2024 at
2:23 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">brian.goetz@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Forgot
to address this part.<br>
<br>
On 1/20/2024 2:00 AM, Smith Wilson wrote:<br>
> It could solve problems with such classes like LocalDate
which require <br>
> more special zeroInstance (1970-1-1) than value with pure
defaults.<br>
<br>
The key thing to realize about LocalDate is that while it is a
good <br>
candidate for being a value type, there is *literally no* good
default <br>
value. Jan 1 1970 is not a good default value, as we've all
seen by <br>
getting emails that tell us our subscriptions are going to
expire 54 <br>
years ago. No other specific date is a good default either.
This is a <br>
statement about the _domain_; there is no good default. (And
when an <br>
abstraction does not have a good default, null is your
friend.)<br>
<br>
Other classes have good defaults; Duration is such an example.<br>
<br>
These two examples (conveniently, from the same package) tell
us a truth <br>
about modeling data with value objects: some classes have
reasonable <br>
defaults (and we can exploit this to optimize their treatment,
and can <br>
freely let people use uninitialized variables, as we do for
primitives <br>
today), and some do not (and hence we need either to engage
nullability, <br>
or work very hard to ensure that an object cannot possibly be
used <br>
uninitialized.<br>
<br>
The reason that "implicit constructor" is a thing is that,
even after <br>
we've identified that a class is a value class, we still have
to <br>
identify something else: whether it is implicitly
constructible or <br>
requires explicit construction. (There's other ways to frame
it, of <br>
course, but the key is that this has to be in the programming
model.)<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>