[foreign] RFR 8208199: Revisit one interface per header file approach

[Samuel Audet]

BTW2, I've recently started to document how to use the InfoMap of 
JavaCPP (this corresponds to what John refers to as "side file") for 
specific situations as a sort of guide:
https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes
I hope that some of these ideas can make there way to jextract...

Samuel

On 08/09/2018 11:57 AM, Samuel Audet wrote:
> BTW, we can do some pretty nasty stuff with the preprocessor. For 
> example, how would jextract handle something like this?
> 
> // header.h
> #ifdef USE_DOUBLE
> #define real double
> #define func(f) f
> #endif
> 
> #ifdef USE_FLOAT
> #define real float
> #define func(f) s ## f
> #endif
> 
> #ifdef USE_HALF
> #define real half
> #define func(f) h ## f
> #endif
> 
> real func(some_function)(real *data);
> int some_other_function();
> 
> In this case, users are expected to include header.h more than once, 
> with different values for the type. Do we create 3 classes? If so, how 
> do we specify their names? Or do we generate only one class with all the 
> functions in them? If so, how do we resolve the inevitable name clashes 
> such as with some_other_function()?
> 
> More to the point, this isn't some imaginary scenario, this is exactly 
> how CMINPACK works, we need to think about those things:
> https://github.com/bytedeco/javacpp-presets/tree/master/cminpack
> 
> Does jextract offer ways to work around this kind of situation? If the 
> community here is serious about scientific applications, we need to 
> think about the libraries we want to support! For example, we could make 
> a list or something and target those...
> 
> Samuel
> 
> On 08/08/2018 10:06 PM, Maurizio Cimadamore wrote:
>>
>>
>> On 08/08/18 13:25, Sundararajan Athijegannathan wrote:
>>>   May I suggest that we go with the current scheme (which is minimal 
>>> changes) and revisit based on use-cases? 
>> While I'm fine with the changes, and I agree that they are 'minimal', 
>> I'm also worried that they add a new design dimension that is not 
>> fully explored. Some of the issues with the approach are the lack of 
>> granularity in specifying the set of headers to be 'followed', as well 
>> as the fact that this new multi-header mode completely invalidates the 
>> assumptions of unresolved layout resolution - the assumption there was 
>> that any layout mentioned in a class C could be resolvable by looking 
>> at the outermost enclosing class of C (**).
>>
>> My feeling is that we have both missing metadata and missing jextract 
>> options here.
>>
>> (**) Consider this example:
>>
>> //a.h
>> import "b.h"
>>
>> void fn(struct S);
>>
>> //b.h
>> struct S { int i; };
>>
>> If you extract this with jextract, you get two headers, one for 'a' 
>> and one for 'b'. The function descriptor for 'fn', which is in 
>> 'a.class' will refer to the layout of S, which is in B.class. With 
>> your patch, a.class will also 'implement' b.class. Here, the resolver 
>> for a.class knows nothing about S. The only way to support this 
>> resolution is via ad-hoc prescanning of all classes in the signatures 
>> of a.class (which we currently do, but it's a mouthful, design-wise).
>>
>> My hope here is to come up with a mechanism to specify related headers 
>> both from a point of view of jextract flag (e.g. so that jextract will 
>> follow headers), but also in a way so that the information about the 
>> header relationship is preserved at runtime into some metadata; that 
>> way, the information can be used to perform layout resolution in a 
>> precise and well-defined way.
>>
>> While this patch defines no additional metadata, one could argue that 
>> the injected subtyping relationship it provides is, itself, some form 
>> of metadata we could exploit during resolution. And, using inheritance 
>> has the obvious advantage of exposing a model that 'makes sense' for 
>> Java users.
>>
>> With all these things in mind, let's give this code a try - and see if 
>> we can fit a story for better layout resolution on top of it.
>>
>> Cheers
>> Maurizio
>>
>>
>