Field initialization before 'super'
    Archie Cobbs 
    archie.cobbs at gmail.com
       
    Wed Dec 13 21:19:56 UTC 2023
    
    
  
On Wed, Dec 13, 2023 at 3:07 PM <forax at univ-mlv.fr> wrote:
>
> captured fields in lambda are like strict but captured fields is inner
>> classes are like normal fields.
>>
>
> I was curious why this would be true and it appears it's not true, at
> least from this test:
>
>
> Yes, but you can still change the value of the field by reflection, unlike
> with the fields of a lambda proxy, so the field containing the captured
> value is not strict.
>
Thanks for the clarification, I missed that piece of it.
> My opinion is also "no" on this question... but because it would add
> another logical fork in developers' minds for too little benefit. It's easy
> enough to just put it in there explicitly.
>
>
> What we are trying to do here, is to follow Dan's idea that there is no
> need for an additional keyword and that the compiler can infer the
> strictness by itself.
> As you said, the problem of that idea is that the developer is not really
> in control, subtle changes like the initializer depending on 'this' make
> the final field strict or not.
>
So it would boil down to the difference between:
   private final int x;  // not strict
   Foo(int x) {
       // implicit super() goes here
       this.x = x;
  }
vs.
   private final int x;  // implicitly strict
   Foo(int x) {
      this.x = x;
      // implicit super() goes here
  }
which only differ in behavior in the introspection and serialization
domains.
Thanks - now I get it.
-Archie
-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20231213/0f55c33b/attachment.htm>
    
    
More information about the amber-spec-observers
mailing list