'package' and access from subpackages..

[Denis Koroskin]

On Fri, 29 Aug 2008 02:52:41 +0400, Jarrett Billingsley  
<kb3ctd2 at 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 :(