2009/2/11 Laurent PETIT <laurent.pe...@gmail.com> > > > 2009/2/10 Stephen C. Gilardi <squee...@mac.com> > >> >> On Feb 10, 2009, at 12:32 PM, Greg Harman wrote: >> >> Let me offer a perspective coming from a Java background: >>> >>> I know that there are subtle differences between a namespace and a >>> Java package, but I still tend to subconsciously consider them >>> analogous: they are container structures for organizing code. The code >>> itself (Java classes, or Clojure files with similarly-grouped >>> functions in a namespace) gets organized into these containers. With >>> this mindset, I've always found it a little counter-intuitive that >>> all .clj files belonging to a particular namespace aren't stored in >>> the same directory*. (This also helps a bit with organization at the >>> file level). >>> >> >> There was a time when the layout was all in one directory: >> >> For ns a.b.c, there was a root directory a/b/c/ within which we had c.clj >> and at which any paths "relative to the namespace root directory" used by >> :load were rooted. >> >> Currently in Clojure, all files associated with namespace a.b.c are (in >> the simplest case) in the directory "a/b", so they are all in the same >> directory, though not the one where a Java package of the same name would >> keep them. >> >> It was with ahead-of-time compilation that this directory layout changed. >> Java packages are logically most analogous to Clojure namespaces, but where >> it's natural to break java packages down into one file per class, it was not >> natural to break Clojure namespaces into one file per function--even though >> that's how the mapping works under the covers. >> > > But that's what Ahead of Time (AOT) compilation does : one class/file for > each function of the namespace, and one init class/file for each clojure > file participating to the namespace. > > >> >> Java, Package, group of Classes around a common theme, typically one file >> per Class >> Clojure, Namespace, group of Functions around a common theme, typically >> one file per Namespace >> >> I think the biggest pragmatic difference boils down to the package/ >>> namespace "bootstrapping." In Clojure, there is one file that "owns" >>> the lib and declares the namespace with (ns) and manually loads the >>> others, which include themselves in the namespace with (in-ns). In >>> Java, every class declares the package, and any can stand alone to >>> "bootstrap" the package (and Java itself loads the classes in). >>> >>> Now I'm not necessarily advocating to change Clojure namespaces to >>> follow Java packages, but it is a subtle paradigm shift for people >>> coming from Java that seems to regularly pop up as a point of >>> confusion. >>> >> >> That's good to keep in mind. Do you have any suggestions for the docs >> around this that would have been helpful to you or might be to others from a >> Java background? > > > As a regular java user, what was most disturbing to me was the introduction > of the concept of "library", made subtly different from the concept of > "namespace", but in the same time with (from the doc) a strong 1 to 1 > relationship. > > What, from my java perspective, I would automatically have done as a mental > "mapping" of concepts is : > * namespace <-> package (one to one relationship) > * library <-> jar (one to one relationship, a jar is a set of packages, a > library would be a set of namespaces) > > and the file directory structure would have followed what is also > represented as ahead of time compilation artefacts : > > * one package for the namespace, named after the namespace segments : ns > foo.bar -> package foo.bar > * some hard coded convention for the ns initializer file. Not necesseraly > repeating the last segment, but named something like "lib.clj" or "init.clj" > -> easy to recognize, easy to be used by tools > * all resources owned by the namespace (in the composite sense, owned as in > "whose lifecycle is of the only responsibility of the namespace) located in > the namespace package (data files, images, properties files, ...) >
I was not a very active user when the discussions over those considerations occured, and I know there is little chance to reconsider this (and maybe the drawbacks to the approach I describe above have already been debated, and I haven't followed them, so sorry if this is just repeating over an already closed debate). But still, I think there will be a lot of people that may have the same "first thought" as I had (regarding the false premonition of how things map together), so maybe, at the minimum, an improvement of the doc to more explicitly eradicate the ambiguity could help new users. Regards, -- Laurent > > > Regards, > > -- > Laurent > > >> --Steve >> >> > > > -- > Cordialement, > > Laurent PETIT > -- Cordialement, Laurent PETIT --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
