Arcane Jill
Joined: 01 Jun 2004 Posts: 10
|
Posted: Wed Jun 16, 2004 3:00 pm Post subject: The organization of the etc. heirarchy. |
|
|
If, as I hope, lots of new projects join in and become part of Deimos, it will become important that we don't start filling up (polluting) the etc namespace in any kind of haphazard way.
I therefore propose that, if you have a project containing more than one module (most projects will, I guess), then the thing to do is: let's say your project is called foo - then all your projects files should go in:
(or subdirectories thereof). The public will be expected to do this:
Quote: | import etc.foo.foo; |
to get full functionality, but of course may also do this:
Quote: | import etc.foo.something_else; |
to get a subset of your project.
For projects which are small enough to fit in a single file, it is important not to fill the main etc namespace up will many small files - so we'll have to come up with some imaginitive plan for each of them, fitting them into a grand heirarchy of things-we-haven't-thought-of-yet.
For myself, I reserve: etc.bigint, etc.unicode, and etc.crypto. (The advertized imports will be etc.bigint.bigint, etc.unicode.unicode, and etc.crypto.crypto. Subprojects of etc.crypto will be etc.crypto.random, etc.crypto.hash, etc.crypto.kgf, and various others.
I recommend that the tiger implementation be etc.crypto.hash.tiger. Although I do have an architecture in mind for the crypto functions, it will be easy enough to retrofit (so that everything in etc.crypto.hash.* employs the same interface), so for now, just keep things as is. Importing etc.crypto.crypto should import etc.crypto.hash.tiger.
Any other heirarchy/organization comments, please post here.
Arcane Jill |
|