Hi, Am 10.02.2009 um 18:52 schrieb Stephen C. Gilardi:
In clojure.contrib we have many unrelated libs under
clojure.contrib. If lazy_seqs.clj (a lib) needed to load functions
from fast_memoize.clj (a load file that defines functions in the
lazy-seqs namespace), would it really be clearer/advantageous to
have a layout like this:
apply_macro.clj
except.clj
fast_memoize.clj
import_static.clj
javalog.clj
lazy_seqs.clj
macros.clj
mmap.clj
ns_utils.clj
prxml.clj
repl_ln.clj
rather than this a layout like this:
apply_macro.clj
except.clj
import_static.clj
javalog.clj
lazy_seqs/
fast_memoize.clj
lazy_seqs.clj
macros.clj
mmap.clj
ns_utils.clj
prxml.clj
repl_ln.clj
I think the latter is much clearer.
I also prefer a deeper directory structure instead of a more flat layout.
I think this is also more consistent with the namespace notion. The namespace allows me to do (more or less) what I want: I can name my functions whatever I like, without fear of clashes with functions of other namespaces. Similar in the directory case: I can name the files (more or less) as I see fit. Of course there is this „more or less“: I cannot have a subnamespace and „load“ file of the same name. But this „more or less“ also applies to namespaces: I can't have a struct and a function of the same name... But the point is: I'm the one in charge, no one messes in the directory of my namespace, so I can easily avoid clashes. In a flat structure, many libs place their „load“ files in the same directory. So clashes may happen, and since more parties are involved resolution gets harder. To avoid such problems, one has to come up with some convention. Most likely some prefix indicating the namespace to which the file belongs.... Somehow we cannot get rid of C habits... IMHO, the second example of Stephen is the better solution. I also use this structure in my projects. Whether this should be enforced by Clojure (via the suggested change), is maybe a different thing. Also my thoughts might be a pathologic example, which will almost never happen.... Anyway: +1 from my side for Stephen's suggestion. Sincerely Meikel
smime.p7s
Description: S/MIME cryptographic signature
