<div dir="ltr">Thanks for the confirmation. Good news!<div><br></div><div>As to 'no restrictions' re size (horizontal - number of fields), fine. But what about depth (vertical - fields that are value objects that in turn contain fields that are value objects etc. all the way down)? No constraint on depth of nesting? </div><div><div><br></div><div><br><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 18, 2024 at 8:21 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <font size="4" face="monospace">Amazingly, yes, value-capable
      abstract classes can have fields.  We thought for many years this
      would never be possible; the Great Initialization Alignment
      (eliminating `vnew` and `withfield` in favor of the `new` and
      `putfield` approach) made this possible.  <br>
      <br>
      The language imposes no restrictions on the number of fields of
      value types.  The VM reserves the right to flatten, or not, based
      on its whims.  One likely whim is that "large" values are usually
      not worth flattening.  But this is invisible to the user; the
      semantics are the same whether or not the object is flattened.<br>
    </font><br>
    <div>On 5/18/2024 1:24 PM, John Bossons
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>Thanks for making this so very clear.</div>
        <div><br>
        </div>
        Two questions/issues:
        <div>(1) It would be helpful to include more on the properties
          of abstract value classes (AVCs) -- perhaps a labelled
          subsection? A specific question not dealt with explicitly in
          the current version: Can an AVC have an instance field, now
          that a value class utilizes the Flexible Constructor Bodies
          JEP? (The alternative is  repetition of that field definition
          and accessor in every subtype, which is potentially
          error-prone). </div>
        <div>(2) It would also be helpful to include some commentary on
          limitations.</div>
        <div>Specifically, although it is clear that the purpose is more
          efficiently defined SMALL value objects, (a) How big is
          'small'? And (b) will the compiler accept value types of any
          size, no matter how deep?</div>
        <div><br>
        </div>
        <div>John</div>
        <div>
          <div><br>
          </div>
          <br>
          <div dir="ltr" class="gmail_signature">
            <div dir="ltr">Phone:  (416) 450-3584 (cell)</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Phone:  (416) 450-3584 (cell)</div></div>