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

Reply via email to