[jsr294-modularity-eg] Nested superpackages

[Glyn Normington]

We are agreed on the semantics, so I think we need to discuss costs vs 
benefits.

The strawman says "Nested superpackage are useful in large projects where 
information hiding between internal components is desired." but class 
names of unexported classes can clash between parents and children, 
siblings, etc. which could cause surprises in a large project. So nested 
superpackages don't seem to deliver the desired information hiding.

What do we really lose by deleting nested superpackages? In these 
situations, my feeling is that "less is more" and deleting this feature 
will strengthen the whole proposal.

Glyn

"Bryan Atsatt" <bryan.atsatt at oracle.com> wrote on 23/04/2007 19:16:19:

> Agreed on both counts. Although developers are used to the 
> restriction that only one instance of a given class name can be 
> defined in a given loader, the nested superpackage suggests another 
> namespace, which would lead to the assumption that this restriction 
> doesn't apply.
> 
> I don't like the bi-directional declarations here, as it will be a 
> maintenance issue. My sense is that nested superpackages wouldn't be
> used much in practice: it's a level of control that I suspect most 
> developers wouldn't feel strongly about, and the overhead of 
> declaring them will be enough of a barrier to prevent their use. 
> Sure, there will be some who would like it, but I don't think the 
> benefit outweighs the added complexity...
> 
> // 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: Monday, April 23, 2007 6:19 AM
> To: JSR 294 Expert Group
> Subject: Re: [jsr294-modularity-eg] Nested superpackages

> 
> "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 _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070424/ca70b545/attachment-0001.html