[jsr294-modularity-eg] Fw: Nested superpackage visibility

[Alex Buckley]

The intuition is that if a type is exported outside a superpackage, then 
it is visible to all members of the parent superpackage.

The members of a superpackage should be 1) the types in its member 
packages, and 2) the members of its nested superpackages.

Combining these concepts, a type exported from one nested superpackage 
is visible in sibling nested superpackages and their children.

Another intuition is that a type is always visible to members of its own 
superpackage (i.e. the superpackage where the type's package is listed 
by 'member package ...'). Therefore, the members of a parent 
superpackage are visible to members of its nested superpackages.

I would encourage observers who have specific informating hiding 
scenarios in mind to write out the superpackage declarations, and send 
them to jsr-294-comments at jcp.org. A (nested) superpackage can export 
individual types, so I don't think the superpackage hierarchy is as 
brittle as Ulf claims below.

Alex

Glyn Normington wrote:
> 
> Rather than continue the discussion in private, I'm forwarding the 
> comment below from the observer who prompted this thread, Ulf 
> Ochsenfahrt, for consideration and to create a public record of the 
> responses.
> 
> I'll let Ulf introduce himself:
>  > Let me shortly introduce myself. My name is Ulf Ochsenfahrt, and I have
>  > studied Computer Science in Rostock, Germany, and Stanford, US. As an
>  > avid Java programmer, I have been following the JSR 294 mailing list
>  > discussion.
> 
> Glyn
> ----- Forwarded by glyn_normington at uk.ibm.com on 28/06/07 02:54 PM -----
> 
> Ulf Ochsenfahrt <ulf at ofahrt.de> wrote on 28/06/2007 10:19:00 AM:
> 
>  > Glyn Normington wrote:
>  > >
>  > > Hi Ulf
>  > >
>  > > Sibling nested superpackages can see each other's exported types. 
> Would
>  > > you like to reword your comment based on that?
>  >
>  > That is a significant clarification, and it makes the proposal more
>  > complex from a conceptual point of view. Instead of just a tree, the
>  > structure becomes something like a tree, but not quite:
>  >
>  >       a
>  >      / \
>  >    [b   c]
>  >    / \   \
>  > [d   e]  f
>  >
>  > In the example, b and c form something like a subsystem (just like in
>  > the 'subsystem' proposal), but without the flexibility.
>  >
>  > The next question must of course be: Are superpackages allowed to access
>  > their siblings children (nephews)? What about cousins?
>  >
>  > The more superpackages are accessible, the weaker the proposal gets
>  > (because there are more and more 'exceptions' to the tree structure),
>  > and the more complex its conceptual model becomes.
>  >
>  > What if a strict separation between b and c is desired? Then we need to
>  > insert dummy nodes into that tree, such that b and c are not mutually
>  > accessible any more.
>  > What if c is supposed to be able to access e? Then both e _and_ d have
>  > to be pulled up to the level of b and c, even though d has nothing to do
>  > with this (supposedly d and e access each other). Talk about brittleness!
>  >
>  > The more superpackages are accessible, the more one must ask whether a
>  > tree is a good idea to represent these kinds of relationships.
>  >
>  > What do you think?
>  >
>  > Cheers,
>  >
>  > -- Ulf
> 
> 
> 
> ------------------------------------------------------------------------
> 
> /
> /
> 
> /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/
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg