experiments in panama code generation

[Maurizio Cimadamore]

On 06/02/2022 02:38, Michael Zucchi wrote:
> Structures and unions are similar.   Classes are typed holders of 
> MemorySegment and have normal java getters and setters, anything can 
> be renamed to be more java-like, fields can be excluded if they're 
> private or not useful, can be read/write and indexed acceess is 
> optional.  It's quit a pity you can't implement Addressable as it 
> would just be so much tidier than having to reimplement the same thing 
> for the same purpose but in an incompatible way. 
So, to go back to the topic of having a scope accessor, if I read this 
correctly, you could _still_ implement everything with your generator, 
but your structs will go from something like:

```
class FooStruct {
     MemorySegment fooSegment;

     private FooStruct(MemorySegment segment) { this.segment = segment; }

     public FooStruct ofAddress(MemoryAddress address, ResourceScope 
scope) { // public API
         new FooStruct(MemorySegment.ofAddress(address, sccope));
     }

     // getters/setters
}

```

to:

```
class FooStruct {
     MemorySegment fooSegment;
     ResourceScope scope;

     private FooStruct(MemorySegment segment, ResourceScope scope) {
          this.segment = segment;
          this.scope = scope;
      }

     public FooStruct ofAddress(MemoryAddress address, ResourceScope 
scope) { // public API
         new FooStruct(MemorySegment.ofAddress(address, scope), scope);
     }

     // getters/setters
}

```

E.g. this is a doable transformation, but I guess you are not satisfied 
by the need to keep track both the segment and the scope (esp. given 
that you need the scope to build the segment). So, while it's doable 
(esp. if using code generator), your argument is that having to repeat 
things feels not very pleasing. Correct?

In case it wasn't clear: I'm not trying to downplay any concerns here - 
but I'm trying to understand if removing the accessor will leave some of 
your code completely broken and without a possibility to get rectified 
as opposed to, (as I suspect) more verbose, but equally functional.

Thanks
Maurizio