[foreign-jextract] RFR: 8261906: Improve jextract support for virtual functions [v4]

[Maurizio Cimadamore]

On Wed, 3 Mar 2021 14:08:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > Having two is problematic in terms of adding the required overloads (e.g. we'd need to make up a new name for both options, which might be hard to decipher).
> 
> Ah right. Maybe we could call the direct accessor `f$call` instead ?
> 
> > It also occurs to me, that, with the currently implemented option, one could still do this:
> > ```
> > func f = header::f;
> > ```
> > 
> > 
> > E.g. if a functional interface is expected, it should be possible to instantiate it using a method reference.
> 
> That's an interesting idea, though I think it only works for global variables? (struct fields require a MemorySegment as well).
> 
> I think in general, when JDK-8259054 is implemented it should be easy enough to get a function interface instance:
> 
> ```
> func x = func.ofAddress(foo.f$get(segment));
> ```
> 
> So, maybe that's another reason to pick the simpler accessor...

I don't know. I think the argument cuts both ways. On the one hand, the simpler accessor seems more direct, but requires also more ad-hoc logic in code generation. On the other hand, if we fix JDK-8259054 and then we generate a function pointer accessor which does what you wrote above, we reuse more of the bits we already generate.

For instance, I like the fact that, by returning a functional interface, we stick to a principle where each bit of generate code does one thing: the accessor creates the functional interface; the apply method on the functional interface does the call (as opposed to have a single method which does both).

In other words, I find this:

foo.f(segment).apply(10, 21F)

*more* readable (not less) than (and less magic than):

foo.f(segment, 10, 21F)

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/456