[jsr294-modularity-eg] iJam

[Alex Buckley]

Rok Strnisa wrote:
> On 18 Sep 2007, at 21:05, Alex Buckley wrote:
>> The paper raises two issues:
>> 1) Sharing a type between two module definitions.
>> 2) Selecting a type in a module definition when import policy and  
>> other
>> artifacts cause multiple types with the same name to be available.
>>
>>  From a 294 perspective, these issues do not arise because of the rule
>> that a type can only be a member of a single superpackage. Indeed, the
>> rule was expressly designed to keep things simple for a Java  
>> programmer
>> who just wants to group related packages together.
> 
> The paper deals with _different_ types that are present in different  
> superpackages (module definitions), but have the same fully-qualified  
> names, either accidentally or on purpose (to override the other type).

Right, for 'type' I should have written 'type definition'.

> Do you mean by "a type can only be a member of a single superpackage"  
> that
> a) "each fully-qualified class name can only appear as a member in a  
> single superpackage", or
> b) "an exact type (represented by an exact classfile) can only appear  
> as a member in a single superpackage"?
> 
> If a), the decision seems too limiting; if b), the decision does not  
> interfere with the idea in the paper.

(b). Superpackages don't talk to each other to limit a type name to one 
definition per VM. You can copy a classfile and modify the copy's 
superpackage information; the two type definitions have the same FQN but 
are in different superpackages statically and dynamically.

Alex