On Jul 7, 7:55 pm, James Reeves <jree...@weavejester.com> wrote: > For the purposes of this discussion, let us assume that "foo" is a > suitably unique library name, and it is highly unlikely there exist > any other libraries with the same name.
It sounds like Clojure doesn't have an idiom for namespace names yet, so I guess we are free to make our own conventions. The Sun/Java notation has the advantage that it scales. Any short one- element name convention will eventually clash, since there are only that many TLAs available. For CCW, a quick Google search tells me that it is an acronym for * Complete Custom Wheels * Countryside Council for Wales * Carlisle Coating and Waterproofing * Coastal Championship Wrestling * etc. etc. etc. I suppose most of those organizations do not ship Clojure code, at least not yet :), but if Clojure grows to see widespread use name clashes are inevitable. The Sun/Java convention is made to scale to the point where everyone in the world can release their own modules without interfering with each other. The disadvantage is of course that you end up with names like org.apache.http.client.params.ClientPNames/ CONNECTION_MANAGER_FACTORY_CLASS_NAME which gets old really quick if you have to type it a lot :) I would like to see a middle ground - somewhat less verbose than Java but still long enough to scale to orders of magnitude more libraries than today. Although aliases go a long way towards making long names less of an issue. So perhaps something like (com|net|org|edu).(author).(project) where 'com' means 'commercial' (for sale), 'org' is open source, 'edu' related to education and 'net' a general-purpose catch-all for remaining cases. This would make it - org.weavejester.foo and we can leave out github as a hosting detail. (As pointed out earlier, the project could move to bitbucket next week.) What I don't like about the leading com/net/... is that we are wasting an entire namespace element and several characters to distinguish four cases, that's just two bits of information... A better alternative might be (where).(who).(what) - github.weavejester.foo although tying the namespace up to a hosting provider doesn't seem ideal either. So perhaps just (who).(what) - weavejester.foo which would get my vote today. If "who" and "what" are both suitably unique today, the combination is unique squared and should be good for a couple of orders of magnitude more growth. It is also the convention used by the Clojure core, as in clojure.set, clojure.xml etc. My proposal would be - for private use: Doesn't matter, "foo" is fine. - for shared libraries with a short- to mid-term life expectancy: Minimum two-element namespace (who).(what) - for larger, long-term libraries, when you hope it will be an industry standard in ten years: Three-element namespace, perhaps (where).(who).(what). IMHO, YMMV etc. I'm new to Clojure and can hardly claim to be qualified to appoint the idiomatic Clojure way, but I think something along these lines gives the best of both worlds - minimizing namespace clashes as well as maximizing readability and reducing typing. jf On Jul 7, 7:55 pm, James Reeves <jree...@weavejester.com> wrote: > On 7 July 2010 17:24, Laurent PETIT <laurent.pe...@gmail.com> wrote: > > > Of course, if your library has an especially cryptic name (as we have > > with counterclockwise: ccw), then having also directly foo may also > > not interfere with other's namespaces. That's the path we took for > > counterclockwise, and our top-level namespace/package is just 'ccw' > > For the purposes of this discussion, let us assume that "foo" is a > suitably unique library name, and it is highly unlikely there exist > any other libraries with the same name. > > - James -- 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 Note that posts from new members are moderated - please be patient with your first post. 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