Creating a high level Pointer API

[Ty Young]

> Note that MemoryAddress is not meant to be implemented by the user, 
> and will be made 'sealed' as soon as the sealing support is made 
> available (by Amber project). So I recommend using aggregation, not 
> subtyping here (e.g. a Crosspoint has-a MemoryAddress, instead of a 
> CrossPoint is-a MemoryAddress (and then expose the address with an 
> accessor, if needed)


Is there an actual reason for this or is it "just because"? The ability 
to plug a Pointer implementation into whatever MemoryAddress argument is 
kind of a big deal with less boilerplate and all. It kinda waters down 
the benefit of higher level abstractions...


Frankly, I don't understand what the benefit of "sealing" an interface 
is - all the code needed to actually implement it is already hidden 
inside modules. Its not like someone can build a MemoryAddress from scratch.


> Seems like a good direction to explore - the fact that you have been 
> able to come up with something so quickly seems a good sign - e.g. 
> that the memory access API has the knobs that are needed to build 
> higher level stuff (which is sort of the claim we're making here).


Primitives are easy. I haven't looked at the old Pointer API code but I 
imagine implemented Struct, Enum, and function callback types are a bit 
more complicated.


How is the new jextract going to handle enums, btw?


> Not sure what you mean by 'home' a pointer, and which piece of 
> functionality you need - I guess you need something to switch between 
> different layouts?
>
> We have plans to rework SystemABI a bit - Jorn and I discussed about 
> making all the ABI implementation class public, so that people can 
> actually 'see them'.
>
> But in your case, I wonder if what you need is more something like 
> we're doing in our LibClang port:
>
> http://hg.openjdk.java.net/panama/dev/file/65925c71ceb3/src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/LayoutUtils.java#l255 
>
>
> And then, when the client creates an 'int' pointer, you just use the 
> right layout (since e.g. C_INT is initialized to point to the right 
> place).


Exactly this. I suppose the "homing" idea could be scrapped and just 
replaced with a "ofNativeInteger", for example. So for each primitive 
type there would be methods like:


"ofJavaInteger" = cross-platform


"ofPlatformInteger" = specific specified platform Integer version


"ofNativeInteger" = runtime platform's ABI integer. Maybe 
"ofRuntimeInteger" would be better instead. Haven't decided.


> We will keep trying to do our best to make the documentation as 
> accessible as possible (but also as complete as possible). I think on 
> the MemoryLayout/MemoryAddress/MemorySegment front we did a good work, 
> I agree that the VarHandle part is not optimal - in part because, as 
> you say, it's just hard.
>
> What you did seems good - I think the 'homing' stuff seems a tad 
> over-engineered, in the sense that I'd just personally prefer a 
> straightforward interface where I can allocate a pointer given 'any' 
> layout, and, perhaps, on the side, give the user a menu of layouts 
> (SysV, Windows, or Portable ones) - perhaps using your Platform 
> abstraction.
>
> In other words, I think your Pointer interface is doing double-duty - 
> it's a pointer (so support dereference, etc.) but it also has several 
> functionalities which have to do with 'finding the right layout'. I 
> think it could be more beneficial to factor these somewhere else. My 
> 0.02$.


I could separate things out but that would result in multiple classes 
that simply provide a way to create Pointers and nothing more. Maybe 
once I actually implement more things I'll figure out something more 
elegant.


>
> Also, you can easily make the Pointer extend AutoCloseable and call 
> free() automatically, so that you can use Pointer inside 
> try-with-resources.


I didn't because, IMO, "free" is a much better word to use but yeah, 
just for try-with-resources support I should probably change it.


>
> Maurizio
>
>>
>>
>> [1] https://github.com/BlueGoliath/Crosspoint
>>