Am Montag, 5. April 2004 10:49 schrieben Sie:
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.
I think, we mean different things. You talk about Foo containing *all* foo stuff whereas I talk about Foo containing the *basic* foo stuff or suff for general foos or whatever. One example is a hierarchy for graph handling code, I used lately. The module <prefix>.Graph contains code for directed graphs, <prefix>.Graph.Acyclic contains a type for the special case of acyclic graphs, etc. Another example are modules about URIs, which I'm currently developing. <prefix>.URI contains the URI type, <prefix>.URI.Scheme contains a type for URI schemes, <prefix>.URI.Hierarchical provides support for the special case of hierarchical URIs and so on.
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.
I don't know if dozens of closely related imports are such a bad thing. The problem with your approach is that it doesn't seem to work if certain names are defined in several of the collected modules. For example, I cannot see how you would create a DData collector module. Another problem I see is that you cannot use the module Foo for general things (see above) which is sometimes useful.
[...]
Cheers, S.
Wolfgang