<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">This is something that we are
actively exploring now, but haven't yet settled on a treatment
of. Though null-retricted != inlined (e.g., String![]). We can
always treat LocalDate![] the same as String![], but we'd like to
do better. Here, there are higher requirements to
initialize-before-possible-use. <br>
<br>
An assignment of null to an Anything![] element will result in an
NPE/ASE (just as today assigning an Integer to an element of a
String[] cast to Object[].) So invalid-values-on-write are
handled. <br>
</font><br>
<div class="moz-cite-prefix">On 1/21/2024 12:20 AM, - wrote:<br>
</div>
<blockquote type="cite" cite="mid:CABe8uE3u=AKDfr4m8aDh=WnDmcZhd1azh-ALQ_1OftRs=9KcmQ@mail.gmail.com">
<div dir="ltr">Hi Brian, from your description of LocalDate![]
comes a contingent question:
<div>Can (non-implicitly constructable) classes now have
null-restricted (inlined) fields of types that are not
implicitly constructable, given these fields will be
initialized by the constructors to valid values? I assume any
assignment of invalid values (notably, null) will simply
result in exceptions such as NPE.</div>
<div><br>
</div>
<div>If yes, how will such fields be represented in heap as:</div>
<div>1. identity object's final fields?</div>
<div>2. identity object's mutable fields?</div>
<div>3. non-implicitly constructable value object's final
fields?</div>
<div><br>
</div>
<div>Given these fields can have their proper states visible no
later than their owner objects are visible.</div>
<div><br>
</div>
<div>I think this is a new aspect of inlining that hasn't yet
been discussed, but is probably worth discussing.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Chen Liang</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Jan 20, 2024 at
2:17 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">
<div> <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>On 1/20/2024 2:41 PM, David Alayachew wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank" 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>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>