Pointer/Scope API questions

[Maurizio Cimadamore]

>>
>> We will start working on pushing an initial implementation for the 
>> minimal extraction tool.
>
>
> If you're sure this is the route you're going towards i'd be happy to 
> take it for a spin if it's in a semi-usable state. Do you plan on 
> doing a basic run down of how to use it?

Of course - in the next few weeks, we plan to (1) push a minimal 
workable jextract tool based on the API, then (2) rework all existing 
documented usages examples of jextract to be based on top of the minimal 
bindings (3) release a binary snapshot with memory access + native 
method handle + minimal jextract.

Does that sound good?

>
>
>>
>>>
>>>
>>> I don't feel like Pointer should be abandoned though. Pointer is an 
>>> interface, not an implementation.... If there are platform specific 
>>> details that need to be worked out then that's an implementation 
>>> issue. jextract can(and actively does) have the ability to dump 
>>> working binding code that can be modified as desired. Could jextract 
>>> not simply have the ability to generate very generic bindings for 
>>> those that just want native access quickly(or don't care about 
>>> cross-platform or whatever else) or as a base to work off of to 
>>> provide higher quality bindings? 
>>
>> As I said, a jextract tool will be provided, only it will not do 
>> exactly what it does today, and the methods it will generate will be 
>> slightly lower level. Exactly how much lower level, is still TBD - we 
>> are at a very early stage, but with more experience working with 
>> minimal bindings, my hope is that we will soon converge to an 
>> idiomatic form that is both usable and, yet, primitive enough to be 
>> extensible.
>
>
> For my use case(example: [1]) currently I'm not even using jextract 
> bindings raw but instead creating a wrapper to convert the C function 
> bindings to an object oriented API. Based on prior discussion on 
> accessing functions not specified in a header, its sounding like the 
> use of jextract can be/is null and void in part or completely if you 
> can just define everything yourself. By the end of this, what benefits 
> is jextract even providing exactly?

I remember your use case - if you have no header, jextract can't help 
you much - it couldn't before, it will not be able to in the future.

But let's not pretend this is the common case - what you are doing in 
[1] is very very very specific. In 99.999999% cases, users do have some 
headers to work with. In which cases jextract will use the info from the 
header to generate all layouts, var handles, method handles, and some 
static wrappers on top.

Maurizio

>
>
> [1] 
> https://github.com/BlueGoliath/GoliathEnviousNative/blob/master/modules/org.goliath.envious.nvml/src/main/java/org/goliath/envious/nvml/local/attributes/utilization/NVMLGPUGraphicsUtilizationAttribute.java
>
>
>>
>> Maurizio
>>
>>