August 28, 2008
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
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
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
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
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
"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
"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
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
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
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