Non-atomicity field questions

[-]

Oops, sorry!

On Wed, May 24, 2023, 2:16 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Did you mean to reply off-list?
>
> On 5/24/2023 3:11 PM, - wrote:
>
>
>
> On Wed, May 24, 2023, 1:48 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>>
>>
>> On 5/24/2023 1:52 PM, - wrote:
>> > Hello, quick question:
>> > If there's a nullable reference field in a null-restricted non-atomic
>> > value class, is this possible:
>>
>> We don't null-restrict classes, we null-restrict variables.  So I think
>> the above pencils out to:
>>
>>      __non-atomic value class X {
>>          public String? s;
>>
>>          public implicit X();
>>          public X(String! s) { this.s = s; }
>>      }
>>
>>      X! x;
>>
>> right?
>>
>
> Yes. The field will be a reference than inlined as values. The constructor
> can be null-friendly in my question as well.
>
>>
>> > 1. Declare a reference field, like a String, without heap pollution
>> > concerns;
>> > 2. Limit the values of fields (of course, permit zero-default values)
>> > for all instances of this class, such as nonnegative long field, null
>> > or String reference containing no tabs, etc.
>>
>> If I understand your question, you want to impose representational
>> invariants, with the proviso that the zero-default representation is
>> always valid.  To do so, you can declare an implicit constructor (which
>> produces the zero-default value) and an explicit constructor which does
>> the plain vanilla argument validation / mapping to representation that
>> constructors always do.
>>
>
> That is exactly what I am looking for. Great!
>
>>
>> > This requires constructors to be executed for non-default instance
>> > creation, but individual field validation is independent, and valid
>> > object state is still the cartesian product of valid individual field
>> > states.
>>
>> The role of a constructor is to establish an object's state consistent
>> with its invariants.  But some invariants are per-field, and some are
>> cross-field:
>>
>>      class NonNegativeInt {
>>          // per-field invariants
>>          NonNegativeInt(int i) {
>>              if (i < 0) throw ...
>>              this.i = i;
>>          }
>>      }
>>
>>      class Range {
>>          // cross-field invariant
>>          Range(int lo, int hi) {
>>               if (lo > hi) throw ...
>>               ...
>>          }
>>      }
>>
>> The choice to accept non-atomicity should include "no cross-field
>> invariants", since a non-atomic value could tear under race.  Plenty of
>> classes, though, are more like NonNegativeInt than Range.
>>
>> Does this answer your question?
>>
>
> Yes. Thank you so much, I indeed just need per-field invariants to hold
> true. The ability to have per-field invariants and nullable object
> reference fields in these classes also makes me think the current name,
> null-restricted (non-atomic) value classes is indeed a better name than
> primitive classes, which suggests behaviors in contrary to the two you've
> confirmed here.
>
> Chen Liang
>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230524/91caef05/attachment.htm>