'package' and access from subpackages..

[Don]

Sean Kelly wrote:
> 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.

I would have thought that . isn't part of the package. So that a 
'package' function would be usable within the library it was designed 
for, but would be private outside it.

   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.

I think that's how it works, but IMHO it's pretty useless. It's the 
higher-level functions which use the lower-level ones; and normally the 
high level stuff is at a lower level in the heirarchy.
Are there any use cases for package which works the other way around?
When would it be good design for a subpackage to use a variable or 
function from a super package?