[jsr294-modularity-eg] Nested superpackages

[Glyn Normington]

"Bryan Atsatt" <bryan.atsatt at oracle.com> wrote on 20/04/2007 18:23:17:

> Yes, but that is certainly a much simpler model. Do you think this 
> is a significant restriction? 

Yes - conceptually it's yukky. I know people could work around it and 
tooling could help, but it seems analogous to not being able to declare a 
local variable because it is already declared in an enclosing scope. I 
would rather scrap nested superpackages.

They also seem pretty limited because, as currently defined, a nested 
superpackage is tightly bound to its parent (it names its parent). So they 
don't provide a naming scope or a unit of reuse.

> 
> // Bryan
> 
> From: jsr294-modularity-eg-bounces at cs.oswego.edu [mailto:jsr294-
> modularity-eg-bounces at cs.oswego.edu] On Behalf Of Glyn Normington
> Sent: Friday, April 20, 2007 6:22 AM
> To: JSR 294 Expert Group
> Subject: [jsr294-modularity-eg] Nested superpackages

> 
> Must a nested superpackage be defined by the same class loaders as 
> its parent (enclosing) superpackage? 
> 
> If so, this would seem to put a restriction on the class names in a 
> nest of superpackages: there must be no duplicates. This is a little
> surprising as it means unexported internals of a (nested) 
> superpackage can cause problems depending on the content of the 
> parent superpackage. 
> 
> Glyn _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg

Glyn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070423/152f84e5/attachment.html