'package' and access from subpackages..

[Jarrett Billingsley]

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.