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

[Maurizio Cimadamore]

On Wed, 3 Mar 2021 14:28:33 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)
>
>> 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)
>> ```
> 
> Yeah, that's a good point. It also gets rid of the somewhat awkward segment prefix argument. Though I'm not sure I'd say that I find the former example less clunky-looking in comparison, it seems clearer that way, which I think is more important. So, you've convinced me ;) Let's go for the functional interface instance accessor.

I've uploaded a new iteration which emits a functional interface getter instead of the direct invoker we were generating before. The code got a bit simpler as the functional interface getter is small to generate compared to the mh invoker wrapper. There's a bit of dance in OutputFactory to get the name of the typedef which corresponds to the functional interface we have generated; the logic is not super robust, in the sense that we're just going to assume that if we see a function pointer type def, there's gonna be a functional interface with same name.

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

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