[foreign] RFR duplicates in named layouts have to be reported as error

[Sundararajan Athijegannathan]

Hi,

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:

* Flat, process wide namespace for named is not good - because that 
limits independently written code potentially loaded by different class 
loader. i.e., arbitrary classes can clash by using the same name. Yes, 
we may impose unique namespace process wide - that is also not 
satisfactory. We may have to force package-name like hierarchical names.

* Layout objects leaking memory: Process wide singleton leaks Layouts 
permanently - even after classes that created those layouts are 
unloaded. Even if we enforce unique names across all classes, we'd still 
have this leaking issue.

For the case you're suggesting, it should not be hard to embed that 
interface in a class with @NativeHeader. And that is needed only if 
named references are used. That is not too bad compared to the current 
process wide singleton solution.

-Sundar

On 26/05/18, 2:43 PM, Maurizio Cimadamore wrote:
>
>
> On 26/05/18 02:07, Sundararajan Athijegannathan wrote:
>> I didn't find so. Only assumption here is that @NativeStruct classes 
>> are nested inside @NativeHeader classes - so that 
>> Util.getNativeHeader can locate the containing native header class. 
>> Unless we want to change the model of 'header' interface contains 
>> 'struct' interface as nested type, there is no issue.
> I think this assumption is bad.
>
> What if I have a struct interface:
>
> @NativeStruct("[i32(get=getX)i32(get=getY)](mystruct)")
> interface MyStruct extends Struct<MyStruct> {
>     int getX();
>     int getY();
> }
>
> And then I do
>
> Scope sc = ...
> sc.allocateStruct(MyStruct.class)
>
> This *has* to work. There are two aspects to what we're doing; one is 
> interop with C headers, but another big part of the story is 
> interfacing with native data. The two use cases are rather orthogonal; 
> of course for jextract generated code the assumption you mention will 
> be valid, but in the general case I don't expect this to be the case.
>
> Maurizio