No segment method for MemoryAddress?

[Ty Young]

On 8/24/20 3:12 AM, Maurizio Cimadamore wrote:
>
> On 22/08/2020 03:45, Ty Young wrote:
>> Doing that increases the amount of generic type declarations for 
>> static methods which are already decently sized:
>>
>>
>> public static <T, E extends NativeValue<T>> E 
>> ofUnsafeValueLayout(MemoryAddress address, ValueLayout layout) 
>
> Without knowing exactly what your code is doing - this seems similar 
> to what we do in jextract to expose global variables (e.g. create 
> unsafe segments based at a certain address, with given size).


It's dual purpose - it can be used to create a usable object directly 
from native or interpret that MemoryAddress as the desired NativeValue 
given the layout.. but that's irrelevant.


How are you supposed to create/use method handles with this new setup? 
Do native bindings now return MemorySegment instead of MemoryAddress? Or 
does it not matter because of Addressable?


I thought it was MemorySegment after reading the link again only to 
change the MethodType and started getting errors about the given 
FunctionDescriptor layouts not being a GroupLayout(what?). MemoryAddress 
seems to still work, but I need to add yet another constructor/static 
factory alternative to everything, making it 3(at least) in total now:


1. for creating a new NativeObject using a layout(often no-args default 
constructor)


2. for interpreting an existing MemorySegment as another existing 
NativeObject


3. for MemoryAddress pointers returned from C


I guess the roles are more distinguished this way(no dual purpose as 
mentioned above), but adding more static methods/constructors isn't 
desirable especially when the code path is basically the same anyway.


>
> Maurizio
>