[foreign] rethinking Panama annotations

[Jorn Vernee]

Hi,

Some thoughts on this:

- I'm a fan of per-method annotations, since that also makes it easier 
to find the layout associated with a given j.l.r.Method. And the 
argument of putting the annotation where they belong resonates with me 
as well.

- About providing alternative names for functions. Your example is:

     @NativeFunction("(u64:v)(byte)v")
     void _byte(Pointer<?> ptr)

I think I prefer either having the name as a separate field:

     @NativeFunction(value="(u64:v)v", name="byte")
     void _byte(Pointer<?> ptr)

Or as a separate annotation:

     @NativeFunction("(u64:v)v")
     @NativeSymbol("byte")
     void _byte(Pointer<?> ptr)

That way the alternative name is harder to miss. With the name-as-field 
idea you can still get the conciseness if the name is unused; 
`@NativeFunction("(u64:v)v")`.

- About `NativeCallback`; to be honest, I like it the way it is right 
now:

     @NativeCallback("(i32)v")
     static interface visitor {
         public void fn(int i);
     }

Since the whole object is the callback on the Java side, not just the 
method. @NativeFunction can only be put on methods, and @NativeCallback 
can only be put on classes, and there is no room to make mistakes there.

- About unresolved layouts: I like your solution, but it's hard to read 
for humans. Have you considered a grammar like hole = `$` `{` layoutExpr 
`}` [annotations]? That should give a clearer visual distinction when 
using unresolved layouts; `[ i32(x) ${foo}(foo) ]`. The ${<name>} syntax 
is also used for instance by maven and Eclipse, so this should have a 
familiarity to it as well.

I think I have a bias because I've mostly had to write/read the 
annotations by hand up until recently. I think there's the question of 
who will actually be reading these annotations; is it intended to be 
just the runtime code, or humans as well?

Cheers,
Jorn

Maurizio Cimadamore schreef op 2018-11-20 02:33:
> Hi,
> I put together a writeup which captures our current thinking w.r.t.
> Panama annotations; the document outlines a possible way to replace
> the current system of toplevel annotations with a leaner system of
> member annotations.
> 
> http://cr.openjdk.java.net/~mcimadamore/panama/panama-annos.html
> 
> Comments welcome.
> 
> Cheers
> Maurizio