[jsr294-modularity-eg] Fw: Nested superpackages feedback

[Glyn Normington]

Oh, the other piece of protocol was that the originator of the feedback 
must agree to having their email forwarded to the EG mailing list and 
archived there. Neil agreed this.

Glyn
----- Forwarded by Glyn Normington/UK/IBM on 26/04/2007 10:24 -----

Glyn Normington/UK/IBM wrote on 26/04/2007 10:23:22:

> Here is some feedback on nested superpackages.
> 
> Note that I checked with the spec. leads about what the protocol 
> should be for forwarding such emails to the EG. They were basically 
> encouraging and advised that feedback containing new arguments would
> be valuable to forward to the EG mailing list whereas feedback 
> simply rehashing arguments and expressing personal preferences would
> be less useful. This particular email is a mixture, so I am 
> forwarding it as-is.
> 
> Glyn
> ----- Forwarded by Glyn Normington/UK/IBM on 26/04/2007 10:16 -----
> 
> Neil Bartlett <njbartlett at gmail.com> wrote on 25/04/2007 11:50:42:
> 
> > In response to your plea to the wider readership on the nested 
> > superpackages issue:
> > 
> > I concur with you and feel that Andreas' use case is unrealistic. In 
> > my experience, if a project is large enough to require information 
> > hiding within itself rather than just hiding from external consumers, 
> > then it is also large enough to require separate compilation and a 
> > deployment technology along the lines of JSRs 291 or 277.
> > 
> > Also, like you, I would expect to be able to reuse names in separate 
> > superpackages, irrespective of ownership by a top-level superpackage. 
> > A flat namespace shared across all members of the top-level 
> > superpackage is counterintuitive.
> > 
> > Superpackages themselves already add significant "conceptual weight" 
> > to Java, and I believe nesting them will make this even less 
> > understandable by unsophisticated developers. For example, as a 
> > trainer I can imagine being asked "if I can have nested superpackages 
> > and nested packages, why does there need to be any distinction 
> > between super and ordinary packages?". Also the idea that nested 
> > superpackages do not complicate the lives of developers who prefer 
> > not to use them is certainly false, and quite naive. Competent 
> > developers have to be able to read and maintain code written by 
> > others. Just because I do not plan to use a feature of the language 
> > myself does not mean that I do not need to understand and be able to 
> > use that feature when it is used by others.
> > 
> > Given the additional complexity and the counterintuitive namespace 
> > aspect, I would like to see a much stronger use case for nesting than 
> > the one Andreas gives.
> > 
> > Regards,
> > Neil

> 
> 
> 

> 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
> 
> 

> 
> 






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/20070426/b86c4019/attachment-0001.html