[foreign] RFR 8220063: Generate LayouType constants as part of jextract output

[Maurizio Cimadamore]

That said, if we really pull more on this string, what you have proposed 
(which is a fine idea) feels like a step in between these two points:

1) raw:

scope.allocateStruct(LayoutType.ofStruct(MyStruct.class));

(which btw, can become just allocateStruct(MyStruct.class))


2) full decorated

MyStruct s = MyStruct.allocate(scope);


Now, this is especially true for allocation, I can but that there are 
other cases where you might want to have access to LayoutTypes in a more 
direct fashion.

But again, this feels like an 'ext' feature; if we do that, I suggest we 
use the TYPE name for the static LayoutType holder, similarly to what 
has been done in Java core classes.

e.g.

MyStruct.TYPE.pointer();


But overall, i can't help but feeling that this is a civilization kind 
of use case; not sure whether hardwiring some behavior in jextract is 
the right way to go here.

Maurizio

On 05/03/2019 16:06, Maurizio Cimadamore wrote:
>
> On top of my head, this looks something more for the Ext code factory 
> than for the main one.
>
> Also, not clear about the changes in LayoutType.ofFunction... there's 
> no inference going on whatsoever, in fact your patch does this
>
> + return LayoutTypeImpl.ofCallback(Address.ofFunction(64, 
> Util.functionof(funcIntf)), References.ofFunction, funcIntf);
>
> Yes, we discussed about changing @NativeCallback while back, but I'm 
> not 100% sure that's the direction we should go, and I'd like not to 
> couple things to it.
>
> Maurizio
>
> On 05/03/2019 15:41, Jorn Vernee wrote:
>> Hi,
>>
>> I'd like to contribute a patch which let's jextract generate 
>> LayoutType constants in typedef annotation classes, and struct 
>> classes for the underlying type. The LayoutType constant has the name 
>> of the typedef or struct with an "_t" suffix.
>>
>> This is useful because;
>>
>> 1.) No need to manually declare a static final LayoutType if you 
>> don't want to call LayoutType.ofStruct(...) everywhere.
>>
>> 2.) If an API uses a type in it's documentation/tutorials, but that 
>> type comes from a typedef, in the generated Jextract bindings you 
>> will just find the typedef annotation with that name. But, if we add 
>> a LayoutType constant to the typedef annotation class, the user has 
>> an easy way to find the underlying type as well. (Very useful with 
>> APIs that use typedefs for pretty much anything. Like the Windows API).
>>
>> I might be a little biased towards this, but I've found that 
>> declaring static final LayoutType constants is a must have in 
>> non-trivial projects. Both to reduce verbosity and to show the name 
>> of the API type in the code, not just the name of the underlying 
>> type. e.g. `scope.allocate(MyType_t)` vs. 
>> `scope.allocate(DOUBLE.array(2))`.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220063
>> Webrev: 
>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8220063/webrev.00/
>>
>> I did 3 other things to implement this:
>>
>> 1.) Drop Address parameter of LayoutType.ofFunction, since we can 
>> just infer that from the @NativeCallback annotation instead.
>> 2.) Fixed issue where a typedef of a function type was not generating 
>> an @NativeCallback class.
>> 3.) Sharpened typing in TypeDictionary and JType w.r.t. 
>> JType.FunctionalInterfaceType.
>>
>> Thanks,
>> Jorn