'package' and access from subpackages..

[Don]

Robert Fraser wrote:
> Don wrote:
>> 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?
> 
> module `builder.compiler.parser` and module `builder.linker.readelf` 
> both use module `builder.util`

But builder.util is not a subpackage of builder.compiler, is it?