Namespace for inner classes in jextract

[Maurizio Cimadamore]

On 10/03/2021 12:43, Duncan Gittins wrote:
>
> If/when jextract supports --symbols includefile to filter by name then 
> it could also incorporate syntax to specify aliases to resolve a name 
> clash, eg "pvalueA=MYpvalueA"
>
True - at the same time this is exactly the kind of things that made us 
gravitate towards the idea of plugins and APIs - e.g. once you start 
pulling on this string there are many "features" that people would want 
to see attached to the "filtering" mechanism:

* give custom names to extracted symbols
* give custom _types_ to extracted symbol (e.g. String instead of 
MemoryAddress, or long -> long long, which is sometimes very helpful to 
achieve cross-platform compatibility)
* map different headers to different packages (according to some 
specified mapping)
* custom getter/setter/accessor names
* filter set of accessors for struct fields (e.g. read-only structs?)
* add custom javadoc to extracted symbols
* add custom pre-amble/post-amble to extracted functions (e.g. to make 
sure that passed segments are not closed while the function is executed)
* specify which functions should have Java -> native state transition 
omitted (e.g. "trivial" functions, in the ForeignLinker API lingo)
* import function-like macros with given explicit signature
* ...

At which point we're well past the point of "filtering".

Don't get me wrong - these are all reasonable things to do (and to ask) 
- but you see the tension here: it's simply not possible to enforce all 
the above with command line options (the previous jextract incarnation 
tried to add some of those, but failed). An API is the "right" level to 
deal with many of these - but there is, I believe, a genuine discomfort 
with the idea of having to write a jextract plugin for something that, 
on paper, seems intuitive enough.

I keep coming back to the idea of some configuration file (which could 
initially pre-populated by jextract itself). While working with config 
files is not as pleasant or expressive as working with code (as 
everything gets compressed down to some kind of serialized form), it 
seems to me one of the few practical way to get there.

An alternative could be to adopt an approach similar to javac annotation 
processors, where jextract could accept a classfile specifying some 
"symbol filter implementation". This implementation will be called by 
jextract before each new symbol is generated, so that the client will 
have the last say over how things will be laid out (and this could be 
done interacting with some kind of API).

Maurizio