Suggestion: alias for single part namespaces
James Reeves
As I understand it, the current best practise for writing Clojure
libraries is to ensure the namespace has at least two parts, e.g
"foo.core". If the namespace has only one part (e.g. "foo"), then when
AOT compiled, the resulting classes will lack a package.
Might I therefore suggest that "foo.core" is considered an alias for
"foo". That is, if a resource named "foo.clj" cannot be found, the
system then tries to load "foo/core.clj", and aliases the "foo.core"
namespace to "foo".
Python has a similar syntax to this, in that "foo/__init__.py" is
considered equivalent to "foo.py" when loading modules. In the case of
Clojure, it seems like "library-name.core" is the most common way of
namespacing a single library, so "core" seems the best equivalent to
"__init__".
Any thoughts on this?
- James
Konrad Hinsen
> As I understand it, the current best practise for writing Clojure
> libraries is to ensure the namespace has at least two parts, e.g
> "foo.core". If the namespace has only one part (e.g. "foo"), then when
> AOT compiled, the resulting classes will lack a package.
As a relatively Java-ignorant person, I wonder why this is a problem. As far as I know, packages are optional in Java. So what are the concrete consequences of a Clojure namespace being outside of a package?
> Might I therefore suggest that "foo.core" is considered an alias for
> "foo". That is, if a resource named "foo.clj" cannot be found, the
> system then tries to load "foo/core.clj", and aliases the "foo.core"
> namespace to "foo".
Another perhaps simpler solution would be to have a package called something like "clj-namespaces" to which all package-less namespaces are attributed. This would imply no change at all for Clojure source code.
Konrad.
James Reeves
> On 07.04.2010, at 14:15, James Reeves wrote:
>
> > As I understand it, the current best practise for writing Clojure
> > libraries is to ensure the namespace has at least two parts, e.g
> > "foo.core". If the namespace has only one part (e.g. "foo"), then when
> > AOT compiled, the resulting classes will lack a package.
>
> As a relatively Java-ignorant person, I wonder why this is a problem. As far as I know, packages are optional in Java. So what are the concrete consequences of a Clojure namespace being outside of a package?
I'm not exactly certain. Would anyone more knowledgeable than I like
to chime in to tell us why single classes without packages are a bad
idea?
> Another perhaps simpler solution would be to have a package called something like "clj-namespaces" to which all package-less namespaces are attributed. This would imply no change at all for Clojure source code.
That approach may cause existing tools some problems. For instance, if
you have a file "src/foo.clj", your compiler has to know that the
generated class file should go in "classes/clj_namespaces/foo.class",
and not "classes/foo.class".
The other disadvantage is that existing libraries would have to
explicitly change their namespaces from "foo.core" to "foo" to use
this more concise namespace syntax. If we just alias "foo.core" to
"foo", existing libraries would not need to change.
- James
Chas Emerick
On Apr 9, 2010, at 10:35 AM, James Reeves wrote:
> On Apr 9, 7:59 am, Konrad Hinsen <konrad.hin...@fastmail.net> wrote:
>> On 07.04.2010, at 14:15, James Reeves wrote:
>>
>>> As I understand it, the current best practise for writing Clojure
>>> libraries is to ensure the namespace has at least two parts, e.g
>>> "foo.core". If the namespace has only one part (e.g. "foo"), then
>>> when
>>> AOT compiled, the resulting classes will lack a package.
>>
>> As a relatively Java-ignorant person, I wonder why this is a
>> problem. As far as I know, packages are optional in Java. So what
>> are the concrete consequences of a Clojure namespace being outside
>> of a package?
>
> I'm not exactly certain. Would anyone more knowledgeable than I like
> to chime in to tell us why single classes without packages are a bad
> idea?
First, namespacing is good. Your foobar library won't have the same
name as my foobar library -- and while you might think "who else would
put code in the same oddly-named namespace as mine?", it's a big world
out there and an ounce of prevention is worth a pound of cure.
More strictly speaking, one cannot use any class in the default
package from any Java class that is in a package. That is the
practical issue that leads to default package use being nonexistent in
the Java space. And, you may not care about Java interop now, but
either (a) you might later, or (b) your users might, now. Finally,
gen-class will simply not work (last I checked) from a single-segment
namespace.
Further, my memory is fuzzy on this, but I recall that at least in the
past, Clojure itself had issues loading namespaces from the default
package. That appears to not be the case now, but in any case, you
may simply be depending on an implementation detail when using a
single-segment namespace.
All in all, using proper namespaces is good hygiene, and there's no
real reason to not use them.
----
Regarding James' original suggestion, I've never liked the apparent
convention (I'd hardly consider it a "best practice") of using
foo.core, if only because when I think "core", I assume the topic is
clojure.core. This is straying from far, far away from technical
merits, but I'm constantly puzzled by the urge to have absolutely the
shortest namespaces as possible; maybe it's just me, but I like having
attribution in the namespace, which makes this issue go away:
cemerick.foobar, net.cgrand.enlive-html, org.danlarkin.clojure-json,
etc.
In any case, the correspondence between namespaces and packages is
pleasantly regular and well-suited for exploitation by existing tools;
introducing complexity there doesn't really help anyone. Besides,
this really isn't so hard:
(:require [foo.core :as foo])
:-)
- Chas
John Williams
On Apr 9, 7:59 am, Konrad Hinsen <konrad.hin...@fastmail.net> wrote:I'm not exactly certain. Would anyone more knowledgeable than I like
> On 07.04.2010, at 14:15, James Reeves wrote:
>
> > As I understand it, the current best practise for writing Clojure
> > libraries is to ensure the namespace has at least two parts, e.g
> > "foo.core". If the namespace has only one part (e.g. "foo"), then when
> > AOT compiled, the resulting classes will lack a package.
>
> As a relatively Java-ignorant person, I wonder why this is a problem. As far as I know, packages are optional in Java. So what are the concrete consequences of a Clojure namespace being outside of a package?
to chime in to tell us why single classes without packages are a bad
idea?
> Another perhaps simpler solution would be to have a package called something like "clj-namespaces" to which all package-less namespaces are attributed. This would imply no change at all for Clojure source code.That approach may cause existing tools some problems. For instance, if
you have a file "src/foo.clj", your compiler has to know that the
generated class file should go in "classes/clj_namespaces/foo.class",
and not "classes/foo.class".
The other disadvantage is that existing libraries would have to
explicitly change their namespaces from "foo.core" to "foo" to use
this more concise namespace syntax. If we just alias "foo.core" to
"foo", existing libraries would not need to change.
Konrad Hinsen
> That approach may cause existing tools some problems. For instance, if
> you have a file "src/foo.clj", your compiler has to know that the
> generated class file should go in "classes/clj_namespaces/foo.class",
> and not "classes/foo.class".
Right, but as I see it there is only one tool that cares: the Clojure compiler.
> The other disadvantage is that existing libraries would have to
> explicitly change their namespaces from "foo.core" to "foo" to use
> this more concise namespace syntax. If we just alias "foo.core" to
> "foo", existing libraries would not need to change.
I'd say that existing libraries AND their clients should be able to continue to work as they do. If someone decides his namespace is called foo.core, then that's it.
On 09.04.2010, at 17:15, Chas Emerick wrote:
> First, namespacing is good. Your foobar library won't have the same name as my foobar library -- and while you might think "who else would put code in the same oddly-named namespace as mine?", it's a big world out there and an ounce of prevention is worth a pound of cure.
No objections, but that is a design rather than an implementation issue. If Clojure (meaning Rich) decides that namespaces should always have at least two parts, then I wouldn't object, for the reasons you give. But then ns should raise an exception when a one-part namespace is created.
The current situation is apparently that one-part namespaces work fine until you do something that most Clojure programs/programmers rarely do (AOT compilation, gen-class, ...). That's not a good situation in my opinion.
> More strictly speaking, one cannot use any class in the default package from any Java class that is in a package. That is the practical issue that leads to default package use being nonexistent in the Java space.
OK, that makes it clear where the restriction comes from, thanks!
> Regarding James' original suggestion, I've never liked the apparent convention (I'd hardly consider it a "best practice") of using foo.core, if only because when I think "core", I assume the topic is clojure.core. This is straying from far, far away from technical merits, but I'm constantly puzzled by the urge to have absolutely the shortest namespaces as possible; maybe it's just me, but I like having attribution in the namespace, which makes this issue go away: cemerick.foobar, net.cgrand.enlive-html, org.danlarkin.clojure-json, etc.
The problem is just what attribution to choose for an evolving project that doesn't clearly belong to one person or organization. Let's say I start a small library today, on my own. Then two other developers join in. A year later some organization likes it so much that it takes over development and support and hires the original authors. Does the library change names twice then? Or is it forever linked to its original author, who may well drop out of the project completely?
Konrad.
Laurent PETIT
2010/4/9 Konrad Hinsen <konrad...@fastmail.net>:
> On 09.04.2010, at 16:35, James Reeves wrote:
>
>> That approach may cause existing tools some problems. For instance, if
>> you have a file "src/foo.clj", your compiler has to know that the
>> generated class file should go in "classes/clj_namespaces/foo.class",
>> and not "classes/foo.class".
>
> Right, but as I see it there is only one tool that cares: the Clojure compiler.
>
>> The other disadvantage is that existing libraries would have to
>> explicitly change their namespaces from "foo.core" to "foo" to use
>> this more concise namespace syntax. If we just alias "foo.core" to
>> "foo", existing libraries would not need to change.
>
> I'd say that existing libraries AND their clients should be able to continue to work as they do. If someone decides his namespace is called foo.core, then that's it.
>
>
> On 09.04.2010, at 17:15, Chas Emerick wrote:
>
>> First, namespacing is good. Your foobar library won't have the same name as my foobar library -- and while you might think "who else would put code in the same oddly-named namespace as mine?", it's a big world out there and an ounce of prevention is worth a pound of cure.
>
> No objections, but that is a design rather than an implementation issue. If Clojure (meaning Rich) decides that namespaces should always have at least two parts, then I wouldn't object, for the reasons you give. But then ns should raise an exception when a one-part namespace is created.
>
> The current situation is apparently that one-part namespaces work fine until you do something that most Clojure programs/programmers rarely do (AOT compilation, gen-class, ...). That's not a good situation in my opinion.
Well, are you sure that "most Clojure programs/programmers" rarely do
AOT compilation and gen-class ? Me not.
And some IDEs do that all the time (who said ccw ? :-) )
>
>> More strictly speaking, one cannot use any class in the default package from any Java class that is in a package. That is the practical issue that leads to default package use being nonexistent in the Java space.
>
> OK, that makes it clear where the restriction comes from, thanks!
>
>> Regarding James' original suggestion, I've never liked the apparent convention (I'd hardly consider it a "best practice") of using foo.core, if only because when I think "core", I assume the topic is clojure.core. This is straying from far, far away from technical merits, but I'm constantly puzzled by the urge to have absolutely the shortest namespaces as possible; maybe it's just me, but I like having attribution in the namespace, which makes this issue go away: cemerick.foobar, net.cgrand.enlive-html, org.danlarkin.clojure-json, etc.
>
> The problem is just what attribution to choose for an evolving project that doesn't clearly belong to one person or organization. Let's say I start a small library today, on my own. Then two other developers join in. A year later some organization likes it so much that it takes over development and support and hires the original authors. Does the library change names twice then? Or is it forever linked to its original author, who may well drop out of the project completely?
>
> Konrad.
>
> --
> You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
>
>
Chas Emerick
On Apr 9, 2010, at 12:15 PM, Konrad Hinsen wrote:
> On 09.04.2010, at 16:35, James Reeves wrote:
>
>> That approach may cause existing tools some problems. For instance,
>> if
>> you have a file "src/foo.clj", your compiler has to know that the
>> generated class file should go in "classes/clj_namespaces/foo.class",
>> and not "classes/foo.class".
>
> Right, but as I see it there is only one tool that cares: the
> Clojure compiler.
IDEs (e.g. supporting go-to-declaration navigation), debuggers,
profilers, code coverage tools, etc etc all expect a particular
relationship between source files and classfiles.
> On 09.04.2010, at 17:15, Chas Emerick wrote:
>
>> First, namespacing is good. Your foobar library won't have the
>> same name as my foobar library -- and while you might think "who
>> else would put code in the same oddly-named namespace as mine?",
>> it's a big world out there and an ounce of prevention is worth a
>> pound of cure.
>
> No objections, but that is a design rather than an implementation
> issue. If Clojure (meaning Rich) decides that namespaces should
> always have at least two parts, then I wouldn't object, for the
> reasons you give. But then ns should raise an exception when a one-
> part namespace is created.
>
> The current situation is apparently that one-part namespaces work
> fine until you do something that most Clojure programs/programmers
> rarely do (AOT compilation, gen-class, ...). That's not a good
> situation in my opinion.
I agree; I'd be perfectly happy if single-segment namespaces caused an
error.
>> Regarding James' original suggestion, I've never liked the apparent
>> convention (I'd hardly consider it a "best practice") of using
>> foo.core, if only because when I think "core", I assume the topic
>> is clojure.core. This is straying from far, far away from
>> technical merits, but I'm constantly puzzled by the urge to have
>> absolutely the shortest namespaces as possible; maybe it's just me,
>> but I like having attribution in the namespace, which makes this
>> issue go away: cemerick.foobar, net.cgrand.enlive-html,
>> org.danlarkin.clojure-json, etc.
>
> The problem is just what attribution to choose for an evolving
> project that doesn't clearly belong to one person or organization.
> Let's say I start a small library today, on my own. Then two other
> developers join in. A year later some organization likes it so much
> that it takes over development and support and hires the original
> authors. Does the library change names twice then? Or is it forever
> linked to its original author, who may well drop out of the project
> completely?
All of that is entirely up to the authors/organizations involved, but
package names often change, or don't, depending on the parties'
preferences. In any case, some attribution is always better than no
attribution.
- Chas
James Reeves
> First, namespacing is good. Your foobar library won't have the same
> name as my foobar library -- and while you might think "who else would
> put code in the same oddly-named namespace as mine?", it's a big world
> out there and an ounce of prevention is worth a pound of cure.
I disagree. If you have two libraries with the same name, it's going
to be confusing even if they have unique namespaces. In practice,
library names are going to be unique, and therefore there's no
advantage to adding the author's domain name to one's namespaces. I'd
argue that it's even detrimental to do so; it makes namespaces harder
to remember, makes it difficult to discern the official version of a
library over a fork, and leads to namespacing changes when the authors
or hosting of a project changes.
Most other programming languages manage fine without Java's practice
of prefixing namespaces with the author's domain. If namespace clashes
were really that big of a problem, then all languages would have
adopted the same convention as Java. As it is, it almost never
happens, and certainly not enough to justify all the disadvantages of
the approach.
> More strictly speaking, one cannot use any class in the default
> package from any Java class that is in a package. That is the
> practical issue that leads to default package use being nonexistent in
> the Java space. And, you may not care about Java interop now, but
> either (a) you might later, or (b) your users might, now. Finally,
> gen-class will simply not work (last I checked) from a single-segment
> namespace.
Ah, thanks for the information. I was half convinced I had dreamed up
that particular restriction. It's nice to know there's a reason, at
least.
> In any case, the correspondence between namespaces and packages is
> pleasantly regular and well-suited for exploitation by existing tools;
> introducing complexity there doesn't really help anyone. Besides,
> this really isn't so hard:
>
> (:require [foo.core :as foo])
It is when you compare:
(:require [foo.core :as foo]
[bar.core :as bar]
[baz.core :as baz])
Or worse, attributed namespaces!
(:require [org.some-user.foo :as foo]
[com.github.blah.bar :as bar]
[net.hosting.user.baz :as baz])
Compared to:
(:require foo bar baz)
The final example is, at least in my view, much more readable. If we
want to encourage people to prefer "require" over "use", shouldn't we
be making require as concise and simple as possible?
- James
James Reeves
> I'd say that existing libraries AND their clients should be able to continue to work as they do. If someone decides his namespace is called foo.core, then that's it.
What I'm proposing is that (:require foo) is equivalent to (:require
[foo.core :as foo]) if there is no existing namespace 'foo. Therefore
existing libraries would continue to work by referencing 'foo.core
directly, but new libraries could take advantage of a more concise
syntax.
Still, I'm not wedded to any particular implementation. I just want a
standard way of using one-part namespaces in libraries. For libraries
that are very simple, there's often no need for multi-part namespaces,
and it's a pain to have to require [foo.core :as foo] or worse,
[org.user.foo :as foo].
- James
Chas Emerick
seen it happen three times, perhaps not coincidentally all in python
environments, where module names are always terse. In each case,
there was an established internal library that conflicted with an
external library being brought in -- but not replacing the former. It
wasn't pretty.
As far as verbosity of require declarations, I agree, but that's
hardly a reason to start changing namespace resolution. If it's
really enough of a pain point, more sugar (or templating, or ns
references, or whatever) can be added to require et al. far more
easily, and without impacting any tooling.
Cheers,
- Chas
John Williams
More strictly speaking, one cannot use any class in the default package from any Java class that is in a package. That is the practical issue that leads to default package use being nonexistent in the Java space. And, you may not care about Java interop now, but either (a) you might later, or (b) your users might, now. Finally, gen-class will simply not work (last I checked) from a single-segment namespace.
James Reeves
> Library name clashes happen more often than you might think. I've
> seen it happen three times, perhaps not coincidentally all in python
> environments, where module names are always terse. In each case,
> there was an established internal library that conflicted with an
> external library being brought in -- but not replacing the former. It
> wasn't pretty.
Out of curiousity, do you recall the name of the library?
> As far as verbosity of require declarations, I agree, but that's
> hardly a reason to start changing namespace resolution. If it's
> really enough of a pain point, more sugar (or templating, or ns
> references, or whatever) can be added to require et al. far more
> easily, and without impacting any tooling.
This essentially would just be sugar, but I take your point.
What I'm after is a way of using single-part namespaces reliably. It
seems that, currently, there may be some problems with that. If there
aren't, it would perhaps be nice to get some official word that single-
part namespaces are safe to use.
I'm not strongly advocating one solution over another, but I'd like to
be able to write small libraries without needing to nest namespaces.
For many simple tools, only one namespace part is necessary, and it
makes the "require" syntax so much more concise.
- James
Richard Newman
>> continue to work as they do. If someone decides his namespace is
>> called foo.core, then that's it.
>
> What I'm proposing is that (:require foo) is equivalent to (:require
> [foo.core :as foo]) if there is no existing namespace 'foo.
Crazy talk. What happens when foo itself requires foo.core, perhaps
transitively? By the time it's come to define its own namespace, foo
is taken by one of its dependencies.
> For libraries
> that are very simple, there's often no need for multi-part namespaces,
> and it's a pain to have to require [foo.core :as foo] or worse,
> [org.user.foo :as foo].
Then those very simple libraries shouldn't use multi-part namespaces
(or they should use immigrate to pull their core into the upper
namespace).
Generally I prefer the slight increase in verbosity of the fully
qualified name to avoid the horror that is Python's brief namespaces.
James Reeves
> > What I'm proposing is that (:require foo) is equivalent to (:require
> > [foo.core :as foo]) if there is no existing namespace 'foo.
>
> Crazy talk. What happens when foo itself requires foo.core, perhaps
> transitively? By the time it's come to define its own namespace, foo
> is taken by one of its dependencies.
Sorry, I was a little unclear. By "there is no existing namespace
'foo", I mean that there is no resource "foo.clj" or "foo.class" on
the classpath. In such a case, it would be safe to fall back to
looking for "foo/core.clj" or "foo/core.class".
> Then those very simple libraries shouldn't use multi-part namespaces
> (or they should use immigrate to pull their core into the upper
> namespace).
Well, that's the problem. Single-part namespaces don't seem safe to
use in all circumstances, due to the whole default package problem. At
least, that seems to be the consensus thus far. If they *are* safe to
use, then obviously we could just use them directly instead of using
my or Konrad's idea.
Immigrating the namespace is an interesting idea, but immigrate has
problems with var bindings. If I have a function that references
foo.core/*bar*, then it won't reference foo/*bar* when immigrated.
As I say, I'm not favouring any particular solution here. I'd just
prefer not to wrap a library in unnecessary namespace layers if I can
help it.
- James
Richard Newman
> prefer not to wrap a library in unnecessary namespace layers if I can
> help it.
Thanks for clarifying. I agree. (I don't actually see a solution that
doesn't introduce some dangerous ambiguity, but I agree with the goal.)
Common Lisp has the concept of a nickname for a package:
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defpackage.html
Nicknames are available for use so long as no other package uses the
nickname as its actual name.
Unfortunately, Clojure and the JVM conflate the search path with the
package hierarchy, so there's no easy way to say "let me use foo as a
nickname (implicit or explicit) for foo.bar.baz" and still have the
search process work.
Chas Emerick
On Apr 9, 2010, at 1:58 PM, James Reeves wrote:
>> Library name clashes happen more often than you might think. I've
>> seen it happen three times, perhaps not coincidentally all in python
>> environments, where module names are always terse. In each case,
>> there was an established internal library that conflicted with an
>> external library being brought in -- but not replacing the former.
>> It
>> wasn't pretty.
>
> Out of curiousity, do you recall the name of the library?
The most recent instance I came across was where the "statlib" module (http://code.google.com/p/python-statlib
) was brought into a project that already had its own "statlib"
module. I don't remember any of the details of the other two
instances, which I encountered much longer ago than that more recent
example. Thankfully, I wasn't involved in the projects that had these
issues -- I was more of a bystander. Perhaps that makes these
examples apocryphal. *shrug*
- Chas