Re: Request for Discussion: changing lib root directory calculation to improve load/:load

[Stephen C. Gilardi]

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.

Current:
        clojure/core$proxy_call_with_super__5127.class

New:
        clojure/core$proxy_call_with_super__5136.class



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 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: The (internal use) __init files move, but in a way that corresponds to the change so it's transparent: 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.

clojure.contrib.sql
clojure.contrib.sql.internal
clojure.contrib.sql.test



I find the repetition in this code:

I don't personally use "load". Instead I use additional namespaces like this: which ends up making the same kind of directory structure I'm proposing for load.

       (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>










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"))



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





Thanks,

--Steve



--~--~---------~--~----~------------~-------~--~----~

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
-~----------~----~----~----~------~----~------~--~---

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". 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. 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. You received this message because you are subscribed to the Google Groups "Clojure" group.

smime.p7s
Description: S/MIME cryptographic signature