[foreign] RFR duplicates in named layouts have to be reported as error
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Mon May 28 12:32:50 UTC 2018
Here's a stab at the current approach; I started with your patch and
tweaked in places.
http://cr.openjdk.java.net/~mcimadamore/panama/panama-binder-v3.html
I think the result is good; the problems you mention are resolved, and
all use cases are supported.
Let me know what you think.
Maurizio
On 28/05/18 11:02, Maurizio Cimadamore wrote:
>
>
> On 28/05/18 09:37, Maurizio Cimadamore wrote:
>>
>>
>> On 28/05/18 07:39, Sundararajan Athijegannathan wrote:
>>> Isolated Structs will work if there are no name definitions or
>>> references in its layout. If there are Unresolved name references in
>>> its layout, then there has to be a 'context' in which the names are
>>> defined/resolved. The context cannot be entire Java process as it
>>> currently is! Two issues with the current code:
>> I agree with all you say. The only thing I'm disagreeing with is the
>> fact that the context has to be the @NativeHeader annotation, as that
>> suggests an header-centric nature that was never intended to be part
>> of the design.
>>
>> Other, more explicit ways to define the context include an explicit
>> annotation which list all the classes where dependent layout can be
>> found. I think I'd like something like this better. Example (names TBD):
>>
>> @NativeStruct("[$(b)](a)")
>> @Friends(B.class)
>> interface A {
>> B b();
>> }
>>
>> @NativeStruct("[$(a)](b)")
>> @Friends(A.class)
>> interface B {
>> A a();
>> }
> Now that I have expressed this more explicitly, another idea emerged -
> what if we assumed that, if no annotation is provided, the context is
> the outermost class? That will work neutrally with both struct and
> header interfaces...
>
> Maurizio
>>
>>
>> Maurizio
>>
>>
>>
>
More information about the panama-dev
mailing list