View mode: basic / threaded / horizontal-split · Log in · Help
September 11, 2008
Re: 'package' and access from subpackages..
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
September 12, 2008
Re: 'package' and access from subpackages..
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?
September 13, 2008
Re: 'package' and access from subpackages..
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`
September 15, 2008
Re: 'package' and access from subpackages..
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?
December 21, 2008
Re: 'package' and access from subpackages..
"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
December 21, 2008
Re: 'package' and access from subpackages..
在 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.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home