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

[Jorn Vernee]

On Wed, 3 Mar 2021 14:15:52 GMT, Maurizio Cimadamore <mcimadamore 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...
>
>> > 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.

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

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