'package' and access from subpackages..

[Robert Fraser]

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`