'package' and access from subpackages..

[Sean Kelly]

Don wrote:
> Sergey Gromov wrote:
>> Jarrett Billingsley <kb3ctd2 at yahoo.com> wrote:
>>> "Sergey Gromov" <snake.scaly at gmail.com> wrote in message
>>>> Another approach is to have hierarchical packages, which sounds 
>>>> close to
>>>> the concept of nested classes and C++ namespaces. So that inner 
>>>> packages
>>>> have access to anything with package access in all outer packages. But
>>>> how do the outer packages communicate with inner? Inner packages are
>>>> required to have interfaces which are public for some outer packages 
>>>> but
>>>> private for some more outer packages. I cannot see an easy solution
>>>> here.
>>> I was thinking that you would put the more generic stuff towards the 
>>> top of the package hierarchy and the more specialized stuff towards 
>>> the bottom, so that the generic stuff wouldn't actually have to 
>>> access the specialized stuff.  I.e. you would declare interfaces in 
>>> package.*, but you would implement them in package.impl.*. 
>>
>> Yes, I'd organize packages that way, too. Now you call 
>> xml.parse(blah). The xml.parse() wants to create an instance of 
>> xml.concreteparser.Implementation. That requires Implementation in 
>> xml.concreteparser to be visible to the xml package. So should 
>> Implementation be public?
> 
> No. It should be 'package'.

I must disagree.  The 'package' qualifier can provide visibility for the 
current package and subpackages, but not superpackages.  Otherwise, a 
'package' variable in my.deeply.nested.Module would be visible to 
modules in:

my.deeply.nested
my.deeply
my
.

ie. it would be public.  Conversely, I think it's reasonable that a 
'package' variable in my.Module should be visible in:

my
my.deeply
my.deeply.nested

Because a package, to me, represents everything in the current package, 
which implicitly includes subpackages.


Sean