In fact, Rich had far better arguments than mines :-) But again, while I agree with you that it may be time to fix things before 1.0, alas, I have no better proposal to make, so I think it's better to stick with the current implementation, and move when the "click" happens in our heads :-)
Regards, -- Laurent 2009/2/10 Stephen C. Gilardi <squee...@mac.com> > > On Feb 10, 2009, at 10:02 AM, Laurent PETIT wrote: > > Hello, >> >> Here are some (quick) thoughts : >> >> - The wikibook example could also be adapted to the new way of doing >> things : having add1, otherfunc and morefuncs files in the same directory as >> ourlib ? >> > > Yes it could. They are, however, logically part of ourlib--they are only > separate for some kind of "file size" or "grouping" convenience. The layout > you propose gives no clue to anyone that they're related. The layout I > propose keeps them together. The remaining uncertainty about whether they > are standalone libs or files that are loaded by another lib is present in > either case. One has to resolve that by looking inside them. > > - if the other "parts" of the lib are not in the same directory/package as >> the "master lib file", where will the functions defined in the loaded parts >> be generated by AOT ? Still in the root package, or in the package with the >> lib name at the end ? If it is the second option, then it doesn't look >> natural to me. >> > > The functions are defined in the namespace whose "ns" form is doing the > loading. There is no change there: > > For example, proxy-call-with-super is a function in one of the files that > would move. Here are the generated class files for it in the Current and New > jars: > > Current: > clojure/core$proxy_call_with_super__5127.class > > New: > clojure/core$proxy_call_with_super__5136.class > > The (internal use) __init files move, but in a way that corresponds to the > change so it's transparent: > > Current: > clojure/core__init.class > clojure/core_print__init.class > clojure/core_proxy__init.class > clojure/genclass__init.class > > New: > clojure/core/core_print__init.class > clojure/core/core_proxy__init.class > clojure/core/genclass__init.class > clojure/core__init.class > > The New case has these grouped together nicely. The Current doesn't. (these > are internal use files, so there's no big advantage to that, but certainly > no disadvantage) > > - Why change ? I'm not sure there is a strong argument to change the way >> it is done currently. Let me explain a little bit more : I too have the >> feeling that the current way of doing things with libs may not be the final >> one. So I think it may change in the future. But I would not like it to >> change too often. It is sufficiently good now (almost that's my point of >> view), and I would like to see it change for a good reason, when experience >> help us grab the correct abstraction. >> > > I don't personally use "load". Instead I use additional namespaces like > this: > > clojure.contrib.sql > clojure.contrib.sql.internal > clojure.contrib.sql.test > > which ends up making the same kind of directory structure I'm proposing for > load. > > I find the repetition in this code: > > (ns example.ourlib >> (:load "ourlib/add1" >> "ourlib/otherfunc" >> "ourlib/morefuncs")) >> > > to be a compelling example. It's ugly and hard to explain. > > I don't have a clear global picture of Clojure's timeline, but now seems a > good time to make this change to me. > > Again, those are very quick thoughts (no more time to think about it right >> now), >> > > Thanks very much for responding! > > --Steve > > > 2009/2/10 Stephen C. Gilardi <squee...@mac.com> >> I came across this when updating the wikibook concepts page, Libraries >> section, to be correct for current Clojure behavior. >> >> In an early implementation of the code that handles libs, the resource >> (file) for lib a.b.c was at the path "a/b/c/c.clj" within classpath. At that >> time it was natural to consider "a/b/c/" as the lib's directory. >> >> Later, the resource for the library a.b.c changed to the path "a/b/c.clj" >> and the lib's directory became "a/b/". >> >> I think the lib handling code should be changed such that the directory >> associated with lib a.b.c is (again) "a/b/c/". >> >> The advantage of this comes into focus most sharply in a ":load" clause >> within "ns". >> >> Here's the updated example from the wikibook: >> >> (ns example.ourlib >> (:load "ourlib/add1" >> "ourlib/otherfunc" >> "ourlib/morefuncs")) >> >> With the change I'm proposing, this would become: >> >> (ns example.ourlib >> (:load "add1" >> "otherfunc" >> "morefuncs")) >> >> Currently core.clj ends with 3 load calls to load in more pieces of >> clojure.core that were each big enough to warrant a separate file. >> >> The directory structure in src/clj/clojure is (in part): >> >> src/clj/clojure/ >> core.clj >> core_print.clj >> core_proxy.clj >> genclass.clj >> >> With the proposed change, this would become: >> >> src/clj/clojure/ >> core/ >> core_print.clj >> core_proxy.clj >> genclass.clj >> core.clj >> >> or, perhaps removing the "core_" prefixes: >> >> src/clj/clojure/ >> core/ >> print.clj >> proxy.clj >> genclass.clj >> core.clj >> >> There is also at least one lib in clojure-contrib that would need to be >> updated. >> >> I welcome discussion of this proposed change with the goal of entering an >> issue and providing a patch. In the patch, I would also update the doc >> string for clojure/require to reflect current Clojure behavior. >> >> Thanks, >> >> --Steve >> >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
