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

[Samuel Audet]

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
> 
>