Heirarchical name space allocation
simonmar at microsoft.com
Tue Apr 13 11:56:03 EDT 2004
> 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
> hierarchical structure:
> * "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.
There is a rough policy, which pretty much repeats what Sven says above,
This is part of the document in fptools/libraries/doc/libraries.sgml,
BTW. Some bits of it are out of date. Perhaps I should separate out
the design guidelines into a separate document.
More information about the Libraries