Heirarchical name space allocation
Sven.Panne at aedion.de
Mon Apr 5 11:49:33 EDT 2004
Wolfgang Jeltsch wrote:
> Am Sonntag, 4. April 2004 16:51 schrieb Sven Panne:
>>I have a small brain and therefore I like simple rules like "Every module
>>Foo simply re-exports the modules Foo.*". :-)
> I've never used this strategy. In my opinion, it makes much sense if a module
> Foo is about general foo things whereas its submodules are about more
> specific things.
That's no contradiction to my rule, e.g. Graphics.Rendering.OpenGL is about
*all* OpenGL stuff, while Graphics.Rendering.OpenGL.GL is about GL and
Graphics.Rendering.OpenGL.GLU is about GLU.
Perhaps I should explain a little bit more what IMHO is a "good use" of the
* "collector" modules: These are a necessity for larger APIs, otherwise you
can easily have dozens of closely related imports. Nobody argued against
this use, IIRC, and we already have a lot of examples of it.
* "selector" modules: There are different implementations Foo.A and Foo.B of
basically the same API, but it's not clear (yet) which one is better. So
Foo simply re-exports one of Foo.A and Foo.B as the default for people who
don't care, but there is still the possibility of using a specific one.
Text.PrettyPrint is an example of this use, although there's currently only
one specific implementation. Another example is Data.STRef, Data.STRef.Lazy,
and Data.STRef.Strict, but the imports are a bit "upside-down" here, something
we should probably change.
* A collection of only loosely related modules Foo.A, Foo.B, ...: Having a
module Foo wouldn't make much sense in this case. A good example for this
is the Data hierarchy.
So I'm not that narrow-minded by supporting only a single rule... :-) But we
should really try to avoid a structure with no clear superset/subset relationship
like, alas, the Foreign module.
More information about the Libraries