'package' and access from subpackages..

[Sergey Gromov]

Jarrett Billingsley <kb3ctd2 at 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