<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Returning to an old syntaxy
topic which is as-yet unresolved. </font></font><br>
<br>
<div class="moz-cite-prefix">On 4/24/2023 7:18 PM, Dan Heidinga
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJq4Gi5UhP2r_+4cLouxbdGoCB6eQcq3QHrYncmSc-F8Vn5NZw@mail.gmail.com">
<div><br>
</div>
<div> I really wanted to cram the non-atomic designation on
constructors as well but it's not really a property of the
instance; rather it describes writes to storage which puts it as
a property of the class. Still trying to come up with a better
intuition for where this belongs.</div>
</blockquote>
<br>
Our journey here has been pulled by multiple forces. On the one
hand, there are four separate things that you can opt out of, and
each of these may have consequences for semantics and performance: <br>
<br>
- opting out of identity<br>
- opting out of the requirement for explicit construction<br>
- opting out of atomicity<br>
- opting out of nullability<br>
<br>
We've largely decided that the first three are declaration-site
properties of the class and the last is a use-site declaration
(there are of course pros and cons of moving the boundary.) We've
also decided that we don't want to lump any of these; each of these
is a decision that should be made explicitly. <br>
<br>
The three declaration-site properties build on each other;
non-atomicity makes little sense for identity objects, and while I
could imagine a sensible semantics for implicit construction of
identity objects, it's just not that useful. So in practice we'll
see one of the following:<br>
<br>
__value class Foo { }<br>
__implictly-constructible __value class Foo { }<br>
__non-atomic __implicitly-constructible __value class Foo { }<br>
<br>
Stacking modifiers up like this has several disadvantages. It gets
annoying fast. You can't use some modifiers without using
prerequisite modifiers. And all the modifiers feel a little
"front-loaded." <br>
<br>
The other approach, which we considered and rejected eralier, is
having three different top-level things (call them B1 class, B2
class, and B3 class.) This seemed out of line, as it seems better
to focus on the commonality rather than the differences. <br>
<br>
I think we were very successful with moving
__implicitly-constructible to a constructor; this reframes
__implicitly-constructible as a property of the class, and making
the implicit value a constructor feels natural. That whittles down
the "long list of modifiers" from three to two, which is progress.
It feels like non-atomic might similarly want to be "demoted"
somewhere syntactically. <br>
<br>
Possibilities include:<br>
<br>
- A modifier like non-atomic<br>
- A modifier on some other class member, such as the constructors
or the fields<br>
- A supertype <br>
- Some other declaration in the class<br>
<br>
We test-drove the modifiers-on-constructor idea and it didn't feel
right; inventing a new kind of declaration in the class also doesn't
seem right. So I'd like to test-drive the supertype idea. <br>
<br>
In an early version, we actually did model this as a supertype,
which we called Tearable (or maybe it was NonTearable.) But I think
we can agree that the T-word isn't quite the right focus. <br>
<br>
What seems like the right focus is a description about the _boundary
of the object_. Ordinarily, an object has integrity; the fields
travel together. A non-atomic object is a looser confederation of
fields; we are explicitly saying "the fields can take separate
routes to their destination." <br>
<br>
I am thinking of something like:<br>
<br>
value class X implements WeakValue { ... }<br>
<br>
where "WeakValue" means that the object is a weak confederation of
its fields. (A WV value class would require an implicit
constructor, as today with non-atomic.) <br>
<br>
(One advantage of using a marker interface like this is that in the
IDE, the user can navigate into WeakValue and see an explanation of
what this means in the WV Javadoc.)<br>
<br>
<br>
</body>
</html>