View mode: basic / threaded / horizontal-split · Log in · Help
August 28, 2008
'package' and access from subpackages..
The language spec says the following about 'package' protection:

"Package extends private so that package members can be accessed from code 
in other modules that are in the same package. This applies to the innermost 
package only, if a module is in nested packages."

What confuses me is the second sentence.  I interpret it as meaning that if 
you have:

pack1.pack2.a
pack1.pack2.b
pack1.c

that a package variable in pack1.pack2.a will be accessible from 
pack1.pack2.b, but not from pack1.c.  This makes sense to me.

But I don't know if or how those words -- "the innermost package only" --  
apply to the case when a package variable is declared in module c and one 
wants to access it from modules a or b.  Since it says "innermost", I'm 
inclined to believe that it was not written to cover the latter case, only 
the former case.

What I continually run into, however, is the latter case.  Say I'm 
redesigning the MiniD implementation so that it's not all in 3 modules like 
it was before.  So I split things out into several modules.  But this is a 
large library -- large compiler, complex interpreter.  Putting all the 
compiler functions or all the interpreter functions into one module is 
exactly what I'm trying to avoid, so I split them up over several modules 
and make the interdependent pieces 'package'.

Now I've got about 40 modules in one package and it's starting to get 
irritating.  So I'd like to start creating subpackages: one for the 
compiler, one for the interpreter, one for the standard libraries.  But the 
problem is that the interpreter needs some of the internal memory-allocation 
stuff, as does the compiler and even the stdlibs.  So what can I do?  I 
can't put the memory allocation stuff in a subpackage since then its package 
members can't be accessed from any other package.  But I also can't put it 
in the superpackage since no subpackages can access it.  I don't want to 
make that functionality public for obvious reasons.

If I were able to access package members from superpackages, however, this 
would be easy.  It also makes sense -- in the above hierarchy, pack1.pack2.a 
*is in* the package pack1, although indirectly, so it should have access to 
pack1.c's package members.

Until then I'm stuck writing my library one level deep and will probably end 
up with 50 to 60 modules in it.  Sigh.
August 28, 2008
Re: 'package' and access from subpackages..
On Fri, 29 Aug 2008 02:52:41 +0400, Jarrett Billingsley  
<kb3ctd2@yahoo.com> wrote:

> The language spec says the following about 'package' protection:
>
> "Package extends private so that package members can be accessed from  
> code
> in other modules that are in the same package. This applies to the  
> innermost
> package only, if a module is in nested packages."
>
> What confuses me is the second sentence.  I interpret it as meaning that  
> if
> you have:
>
> pack1.pack2.a
> pack1.pack2.b
> pack1.c
>
> that a package variable in pack1.pack2.a will be accessible from
> pack1.pack2.b, but not from pack1.c.  This makes sense to me.
>
> But I don't know if or how those words -- "the innermost package only" --
> apply to the case when a package variable is declared in module c and one
> wants to access it from modules a or b.  Since it says "innermost", I'm
> inclined to believe that it was not written to cover the latter case,  
> only
> the former case.
>
> What I continually run into, however, is the latter case.  Say I'm
> redesigning the MiniD implementation so that it's not all in 3 modules  
> like
> it was before.  So I split things out into several modules.  But this is  
> a
> large library -- large compiler, complex interpreter.  Putting all the
> compiler functions or all the interpreter functions into one module is
> exactly what I'm trying to avoid, so I split them up over several modules
> and make the interdependent pieces 'package'.
>
> Now I've got about 40 modules in one package and it's starting to get
> irritating.  So I'd like to start creating subpackages: one for the
> compiler, one for the interpreter, one for the standard libraries.  But  
> the
> problem is that the interpreter needs some of the internal  
> memory-allocation
> stuff, as does the compiler and even the stdlibs.  So what can I do?  I
> can't put the memory allocation stuff in a subpackage since then its  
> package
> members can't be accessed from any other package.  But I also can't put  
> it
> in the superpackage since no subpackages can access it.  I don't want to
> make that functionality public for obvious reasons.
>
> If I were able to access package members from superpackages, however,  
> this
> would be easy.  It also makes sense -- in the above hierarchy,  
> pack1.pack2.a
> *is in* the package pack1, although indirectly, so it should have access  
> to
> pack1.c's package members.
>
> Until then I'm stuck writing my library one level deep and will probably  
> end
> up with 50 to 60 modules in it.  Sigh.
>
>

I agree.

I have a library and interfaces are stored at the root of the package,  
like this:

gui.control.Button.d
gui.control.Label.d
gui.control.TreeView.d etc

However, platform-dependent implementations are stored one level deeper:
gui.control.win32.ButtonImpl.d - defines a class that implements Button  
interface
gui.control.win32.LabelImpl.d etc

I want to define some methods as package, but in this case sub-package  
modules aren't able to access them. That's why they are public for now :(
August 29, 2008
Re: 'package' and access from subpackages..
On Thu, 28 Aug 2008 18:52:41 -0400, "Jarrett Billingsley"
<kb3ctd2@yahoo.com> wrote:

>
>Until then I'm stuck writing my library one level deep and will probably end 
>up with 50 to 60 modules in it.  Sigh. 
>

I think many D users are having the same problem, me included.
August 29, 2008
Re: 'package' and access from subpackages..
Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
> What I continually run into, however, is the latter case.  Say I'm 
> redesigning the MiniD implementation so that it's not all in 3 modules like 
> it was before.  So I split things out into several modules.  But this is a 
> large library -- large compiler, complex interpreter.  Putting all the 
> compiler functions or all the interpreter functions into one module is 
> exactly what I'm trying to avoid, so I split them up over several modules 
> and make the interdependent pieces 'package'.
> 
> Now I've got about 40 modules in one package and it's starting to get 
> irritating.  So I'd like to start creating subpackages: one for the 
> compiler, one for the interpreter, one for the standard libraries.  But the 
> problem is that the interpreter needs some of the internal memory-allocation 
> stuff, as does the compiler and even the stdlibs.  So what can I do?  I 
> can't put the memory allocation stuff in a subpackage since then its package 
> members can't be accessed from any other package.  But I also can't put it 
> in the superpackage since no subpackages can access it.  I don't want to 
> make that functionality public for obvious reasons.
> 
> If I were able to access package members from superpackages, however, this 
> would be easy.  It also makes sense -- in the above hierarchy, pack1.pack2.a 
> *is in* the package pack1, although indirectly, so it should have access to 
> pack1.c's package members.
> 
> Until then I'm stuck writing my library one level deep and will probably end 
> up with 50 to 60 modules in it.  Sigh. 

I can see two approaches to packages: plain and hierarchical.

D, like Java, uses the plain approach: each package is on its own, and 
packages communicate via public and protected interfaces. This 
necessitates introducing additional, documentation-level contracts on 
which packages of a library are interface and which are implementation 
details.

A pre-compiled library can enforce this by supplying .di files only for 
interface modules. It also can encourage the proper use by supplying a 
single import module.

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.

-- 
SnakE
August 29, 2008
Re: 'package' and access from subpackages..
Jarrett Billingsley wrote:
> If I were able to access package members from superpackages, however, this
> would be easy.  It also makes sense -- in the above hierarchy,
> pack1.pack2.a *is in* the package pack1, although indirectly, so it should
> have access to pack1.c's package members.


I agree and from a short look at the sources, it should be an easy change to
access.c:hasPackageAccess. 

1) Could this change break any existing code? I don't think so, but am not
entirely sure.

2) If it can't break any code, can we get it applied D1?

Christian
August 29, 2008
Re: 'package' and access from subpackages..
"Christian Kamm" <kamm-incasoftware@removethis.de> wrote in message 
news:g99i3t$2gfj$1@digitalmars.com...
> Jarrett Billingsley wrote:
>> If I were able to access package members from superpackages, however, 
>> this
>> would be easy.  It also makes sense -- in the above hierarchy,
>> pack1.pack2.a *is in* the package pack1, although indirectly, so it 
>> should
>> have access to pack1.c's package members.
>
>
> I agree and from a short look at the sources, it should be an easy change 
> to
> access.c:hasPackageAccess.
>
> 1) Could this change break any existing code? I don't think so, but am not
> entirely sure.

It would make what's currently an error not an error, so no, I don't think 
so.

> 2) If it can't break any code, can we get it applied D1?

For some reason W doesn't seem to agree.  He doesn't want *any* changes 
going into D1, breaking or not.

But if it's not specified, I don't know how you can call it a "change," 
simply a "clarification."  I.e. .tupleof used on structs with private 
members (which used to give an error in D1.  I was unable to convince W when 
he fixed this in D2, but for some reason, he went ahead and changed it when 
someone else filed a bug report, go figure.)
August 29, 2008
Re: 'package' and access from subpackages..
"Sergey Gromov" <snake.scaly@gmail.com> wrote in message 
news:MPG.2322860868338f629896b1@news.digitalmars.com...

> I can see two approaches to packages: plain and hierarchical.
>
> D, like Java, uses the plain approach: each package is on its own, and
> packages communicate via public and protected interfaces. This
> necessitates introducing additional, documentation-level contracts on
> which packages of a library are interface and which are implementation
> details.
>
> A pre-compiled library can enforce this by supplying .di files only for
> interface modules. It also can encourage the proper use by supplying a
> single import module.
>
> 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.*.
August 30, 2008
Re: 'package' and access from subpackages..
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?

-- 
SnakE
September 11, 2008
Re: 'package' and access from subpackages..
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'.
September 11, 2008
Re: 'package' and access from subpackages..
Don <nospam@nospam.com.au> 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'.

Let me define the package structure a bit clearer.

There's an xml.parser.Parser class.  It's in module parser, in package 
xml.  There are other modules in package xml as well.

There's an xml.concreteparser.mainmodule.ConcreteParser class. It's in 
concreteparser sub-package in xml package.  There are other modules in 
concreteparser package responsible for the concrete parser 
implementation.

Now xml.parser.Parser wants to create an instance of 
xml.concreteparser.mainmodule.ConcreteParser.  Giving package access to 
ConcreteParser makes it visible to all the modules in concreteparser 
package but not in xml package.

Now I'm all ears.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home