[foreign] RFC: unify function and layout

[Jorn Vernee]

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).

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