Don wrote:
> Sergey Gromov wrote:
>> Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
>>> "Sergey Gromov" <snake.scaly@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

Sean Kelly wrote:
> Don wrote:
>> Sergey Gromov wrote:
>>> Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
>>>> "Sergey Gromov" <snake.scaly@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?

Don wrote:
> Sean Kelly wrote:
>> Don wrote:
>>> Sergey Gromov wrote:
>>>> Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
>>>>> "Sergey Gromov" <snake.scaly@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`

Robert Fraser wrote:
> Don wrote:
>> Sean Kelly wrote:
>>> Don wrote:
>>>> Sergey Gromov wrote:
>>>>> Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
>>>>>> "Sergey Gromov" <snake.scaly@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?

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:g97a7k$u5a$1@digitalmars.com...

I've created a bugzilla entry for this, if you'd like to vote for it.

http://d.puremagic.com/issues/show_bug.cgi?id=2529

在 Sun, 21 Dec 2008 11:58:25 +0800，Jarrett Billingsley <kb3ctd2@yahoo.com> 写道:

> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message
> news:g97a7k$u5a$1@digitalmars.com...
>
> I've created a bugzilla entry for this, if you'd like to vote for it.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=2529
>
>

It's pretty appealing to create another qualifier rule or something for this practical programming. I think it's quite important to have the ability to do a finer grain of packaging at least in the case of MiniD.