[foreign] RFC: unify function and layout

[Maurizio Cimadamore]

Thanks for the comments

On 25/11/2018 13:22, Jorn Vernee wrote:
> Hi,
>
> Some comments:
>
> - The Address.PointeeKind enum could be made private.
>
> - Maybe AbstractDescriptor.dup should be named `withAnnotations` instead?
>
> - Descriptor.java is missing the copyright header.
>
> Otherwise this looks like a good move to me :)
>
> ---
>
> Alternatively; have you thought about removing the PointeeKind of 
> Address altogether, and just keeping an `Optional<Descriptor>` as a 
> field? You could also consolidate the `function()` and `layout()` 
> methods into 1 (function() is unused right now).

I thought about that - I believe that yes, clients could achieve similar 
functionalities with instanceof tests, and maybe once pattern matching 
will be there, they will prefer doing so anyway. But in the meantime, 
function() and layout() seems like pragmatic shortcuts that allow 
clients to make some assertions around the nature of the address layout 
they are operating on. So I guess I'd be inclined to keep them, at least 
until language support significantly improves in the pattern matching 
direction.

Maurizio

>
> Incremental webrev: 
> http://cr.openjdk.java.net/~jvernee/panama/webrevs/descs/webrev.00/
>
> Cheers,
> Jorn
>
> Maurizio Cimadamore schreef op 2018-11-23 19:21:
>> Hi,
>> I've put together a patch which unifies both Layout and Function under
>> a common root type, called Descriptor:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/layout%2bfunc_v2/
>>
>> The reason why I explored this direction is that there are few points
>> where we need some commonality between layouts and functions; for
>> instance, we have already discussed how function descriptors will need
>> to support some form of annotation (in the style of layout
>> annotations); this is needed both by the new annotation format under
>> discussion in [1] but also if we are to give 'names' to callbacks, so
>> that we can refer to function descriptors 'by name' (this is useful in
>> cases like qsort).
>>
>> Another pain point is that the Address layout currently pays the
>> biggest price for the lack of such common abstraction: a pointer can
>> either point to a memory location (object in C lingo) or to a
>> function. If we unify these two, then all Address layouts point to an
>> (optional, because of void) descriptor, and the API can be simplified
>> (a lot, in fact).
>>
>> There's also some hiccups around parsing declaration in @NativeHeader,
>> although this is transitory and will go away if we switch to a
>> different annotation scheme.
>>
>> Overall, after playing with it, I believe this patch significantly
>> improves the API, w/o adding significant complexity/surface area.
>>
>> Comments?
>>
>> Cheers
>> Maurizio
>>
>> [1] -
>> http://mail.openjdk.java.net/pipermail/panama-dev/2018-November/003220.html 
>>