Idiomatic Clojure namespace names
James Reeves
a suggestion, and the discussion got bogged down with no real answer.
So this time, let me keep it simple: if I have a small Clojure
library, "foo", which only has one namespace, what is the idiomatic
name for that namespace?
- foo
- foo.foo
- foo.core
- com.github.weavejester.foo
I don't intend to call "foo" from Java, so there is no genclass in the
namespace definition, and I do not intend to AOT compile the
namespace.
- James
Laurent PETIT
2010/7/7 James Reeves <weave...@googlemail.com>:
I would say:
if this library is only for you, and you don't intend to share it
-ever-, then "foo" for the namespace is good.
if you intend to share the library, then use the classical prefix notation:
* either of the form net.reeves.james.foo ( or any reversed tld you "own" )
* either of the form com.yourcorp.foo
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'
My 0.02 €,
--
Laurent
Peter Schuller
love that fact that Clojure got namespaces "right" in the sense of
allowing aliasing on import. Some languages don't do this, and you end
up with very difficult naming issues since you suddenly have a huge
desire to keep it short *while* also meaningful, structured and
non-clashing.
+1 for clojure :)
--
/ Peter Schuller
James Reeves
> 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
Meikel Brandmeyer
Am 07.07.2010 um 18:13 schrieb James Reeves:
> - foo.core
> - com.github.weavejester.foo
I would go with one of these two. At the moment I prefer the former. I think putting domain names in the package is suboptimal for a quite simple reason. I'm a hobbyist. I don't own a domain. Eh? What to put there? nil.foo? So I choose the hosting site. com.google.code.foo. Ah. I move to github. So rename everything to com.github.foo. Iegh. github sucks. So next rename to org.gitorious.foo. Ah. I like mercurial better. org.bitbucket.foo.
Ok. That's a little far-fetched but it happens (jetty).
Sincerely
Meikel
Pedro Henriques dos Santos Teixeira
if "foo" is to be shared on public repos, a prefix denotating its
author or origin is quite essencial -- especially in these "github"
days. For instance, it would be best if the namespaces relate to the
project/jar name in the repo. Right?
Perhaps, immigrate can be used to hide long namespace names
(ns foo)
(immigrate 'origin.foo)
>
> - James
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
Saul Hazledine
> if you intend to share the library, then use the classical prefix notation:
>
> * either of the form net.reeves.james.foo ( or any reversed tld you "own" )
> * either of the form com.yourcorp.foo
>
Mike Meyer
"Meikel Brandmeyer" <m...@kotka.de> wrote:
>Hi,
>
>Am 07.07.2010 um 18:13 schrieb James Reeves:
>
>> - foo.core
>> - com.github.weavejester.foo
>
>I would go with one of these two. At the moment I prefer the former. I think putting domain names in the package is suboptimal for a quite simple reason. I'm a hobbyist. I don't own a domain. Eh? What to put there? nil.foo? So I choose the hosting site. com.google.code.foo. Ah. I move to github. So rename everything to com.github.foo. Iegh. github sucks. So next rename to org.gitorious.foo. Ah. I like mercurial better. org.bitbucket.foo.
Why bother renaming it when you move? You're going to want to put a redirect up at the old site anyway. Just leave it there until the project dies.
That's actually better than using your own domain name. Should you change domain names, you have to keep paying for it or loose it. With a repo provider, it's generally free.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Meikel Brandmeyer
Am 07.07.2010 um 21:41 schrieb Mike Meyer:
> Why bother renaming it when you move?
Why come into a situation where bothering is a question?
Sincerely
Meikel
PS: You K-9 Mail sends every message twice.
Mike Meyer
"Meikel Brandmeyer" <m...@kotka.de> wrote:
>Hi,
>
>Am 07.07.2010 um 21:41 schrieb Mike Meyer:
>
>> Why bother renaming it when you move?
>
>Why come into a situation where bothering is a question?
You would have to ask the people at sun.com who created the convention that one.
>PS: You K-9 Mail sends every message twice.
Certainly, if an address you read is on the recipient list twice.
j-g-faustus
> 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.
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:
Mike Meyer
j-g-faustus <johannes...@gmail.com> wrote:
> 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.
You're overlooking that one of the major benefits of Clojure is that
it interoperates with other JVM languages. So any idiom it uses needs
to have some assurance that it won't clash with an idiom used by thsoe
other languages. Ditto for the CLR. The very first thing I did with
clojure was grabbed a Java library - and all the things it depended on
- and wrote some test code to play with it.
> 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.
That the Oracle/Sun/java way scales is a good reason to do it their
way. Except that I notice that Sun doesn't do that: the libraries I've
got from them are javax.comm, *not* com.sun.javax.comm (being renamed
to com.oracle.sun.javax.comm, I suppose).
> 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.
If I ever add AJAX widgets to bitchen' it's going to be the "Cool
Clojure Widgets" library. Just 'cause.
> 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.
It will happen long before that for clojure users if they incorporate
non-clojure libraries.
> 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.
Just so long as everyone follows that convention. As far as I know,
Sun didn't do anything to enforce that, or even to prevent people from
shipping code in namespaces in a domain name they don't own.
> 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.
By picking the DNS TLD's, you're *asking* for collisions with the DNS
namespace. Unless you want to use XXX, of course.
The first component needs to be something that is 1) isn't likely to
collide with a DNS namespace, and 2) isn't likely to be used by any
other language.
Given that Sun is using javax, something like
"clojure.(author).(project)" would seem to be appropriate. That should
be safe from the DNS namespace (unless it means something when
transliterated into a foreign language) nor is a project in a language
other than clojure likely to use it.
Of course, if you google for "Mike Meyer", you'll find (on the first
page I get from google) a photographer, an artist, a statistician, an
online educator, an astrophysicist (I seem to be an intellectual
bunch), a sports commentator, and a Canadian comedian who doesn't
spell his last name right. At least the mass murderer has fallen out
of the rankings. In the past, I've gotten party invitations meant for
another Mike Meyer, been handed the wrong paycheck, been asked how my
kids were (long before I had any myself), and once even collaborated
with myself on extending the emacs MH-E package.
So maybe that's not so good. Especially if your name is "Muhammad",
"Chen", or "Smith".
> 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...
As above, that namespace needs to be used to distinguish clojure from
everything else that runs on the JVM.
> 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.
Actually, the WWW consortium found out the hard way that using URL as
namespaces for schema was a *bad* idea. They weren't supposed to
actually be used to find the schema, but the www made them available
that way, and people wrote code to use them. When the WWW realized
that their servers were being ground to dust by people fetching the
schemas, they moved them, and a lot of software quit working.
If you're going to use a repo server as part of the name space, it
must be clear that this doesn't mean that's where the project lives:
it just provides a namespace for the library, and looking for sources
or jars there is the *wrong* thing to do.
> 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.
I don't believe either is suitably unique today, since you're not
doing anything to distinguish this from *other* languages on the jvm.
> It is also the convention used by the Clojure core, as in clojure.set,
> clojure.xml etc.
Clojure (like Java) gets a special pass: if you're writing in Clojure,
you're using the Clojure (and probably some java) libraries, so you
know that those namespaces are taken.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Michael Gardner
> 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 :)
Why would you ever type that more than once? Just use :as.
Daniel Gagnon
Why would you ever type that more than once? Just use :as.
j-g-faustus
> You're overlooking that one of the major benefits of Clojure is that
> it interoperates with other JVM languages. So any idiom it uses needs
> other languages.
It's a good point.
> That the Oracle/Sun/java way scales is a good reason to do it their
> way. Except that I notice that Sun doesn't do that: the libraries I've
> got from them are javax.comm, *not* com.sun.javax.comm (being renamed
> to com.oracle.sun.javax.comm, I suppose).
> Just so long as everyone follows that convention. As far as I know,
> Sun didn't do anything to enforce that, or even to prevent people from
> shipping code in namespaces in a domain name they don't own.
the convention, perhaps because it was part of the language
specification
http://java.sun.com/docs/books/jls/third_edition/html/names.html#73307
and included in every language tutorial.
Or perhaps in part because it plays to individual or organizational
vanity when you can stamp your identity right there in the code.
I don't think there is anything directly stopping J. Random Hacker
from shipping code as com.ibm or com.apple, although their lawyers
might have something to say about that.
So maybe it's best to use the Java convention after all?
It has been proven to scale, is widely used and plays well with
whatever else is running on the JVM, which are strong points in its
favor.
jf
Meikel Brandmeyer
On Jul 8, 7:25 am, j-g-faustus <johannes.fries...@gmail.com> wrote:
> So maybe it's best to use the Java convention after all?
> It has been proven to scale, is widely used and plays well with
> whatever else is running on the JVM, which are strong points in its
> favor.
years from contiteves.com over contiautomative.com to continental-
corporation.com and maybe its soon schaeffler-continental-automotive-
group.com or whatever. Should I always touch each and every code
module to fix the package names?
Just to understand the problem (honest questions; I don't know the
answers): How many open source projects are out there, which have the
same names? Is a clash in project names, that likely?
What happens with the prefix-with-your-domain prefix can be seen on
clojars at the moment. People upload stuff under names they don't own.
There are several vimclojure packages. Not a single of these are
projects on their own right. Just variants of mine. Maybe patched,
maybe not. Nothing is documented. How does that help anything? How
should the casual user know which is the official one?
Maybe following the Java convention is good. Maybe not. What is the
convention on the CLR? What happens if both conventions contradict? We
should choose a convention based on arguments and not based on what
others do.
Sincerely
Meikel
Mike Meyer
Meikel Brandmeyer <m...@kotka.de> wrote:
> Hi,
>
> On Jul 8, 7:25 am, j-g-faustus <johannes.fries...@gmail.com> wrote:
>
> > So maybe it's best to use the Java convention after all?
> > It has been proven to scale, is widely used and plays well with
> > whatever else is running on the JVM, which are strong points in its
> > favor.
>
> I still don't buy it. The company I work for changed its domain over 4
> years from contiteves.com over contiautomative.com to continental-
> corporation.com and maybe its soon schaeffler-continental-automotive-
> group.com or whatever. Should I always touch each and every code
> module to fix the package names?
Nope. You can if you want to, in which case this is a relatively cheap
thing to do (one command per source pool in a good refactoring editor,
or a shell script your most junior developer should be able to write
in an hour) compared to the changing things like business cards,
stationary, and everything else that might mention the domain name.
The only globally unique namespace I know of that doesn't change over
time is UUID. Would you rather use that?
> Just to understand the problem (honest questions; I don't know the
> answers): How many open source projects are out there, which have the
> same names? Is a clash in project names, that likely?
Based on my personal experience, it's slightly more likely than a
change in domain names. My company has changed it's domain names twice
in two decades, and had three oss projects whose names clashed with
other projects. I've had one client whose changed a domain name
because a much larger company "convinced" him to sell, but I also know
about names like Icon, which has been attached to several
projects. And of course, we've already got the Clojure CDT project
which apparently clashes with some usage in an IDE somewhere.
> What happens with the prefix-with-your-domain prefix can be seen on
> clojars at the moment. People upload stuff under names they don't own.
Obviously, some people don't care about making sure their namespaces
don't collide, and will ignore any convention. Since all conventions
will suffer from this, it's not really a factor.
Also, it's not about ownership, it's about control. All that matters
is that no on else following the convention will use the prefix, no
matter who owns it.
> There are several vimclojure packages. Not a single of these are
> projects on their own right. Just variants of mine. Maybe patched,
> maybe not. Nothing is documented. How does that help anything? How
> should the casual user know which is the official one?
So package name collisions are pretty common - *especially* for forked
projects. But this still appears to be a problem that any convention
will have, so it's not really a factor. I mean - if everyone who
forked the project changed the name, would it still help someone find
"the official one" (whatever that means)?
> Maybe following the Java convention is good. Maybe not. What is the
> convention on the CLR? What happens if both conventions contradict? We
> should choose a convention based on arguments and not based on what
> others do.
That's raises several interesting questions, and should certainly be
considered.
Chas Emerick
On Jul 8, 2010, at 10:15 AM, Meikel Brandmeyer wrote:
> What happens with the prefix-with-your-domain prefix can be seen on
> clojars at the moment. People upload stuff under names they don't own.
> There are several vimclojure packages. Not a single of these are
> projects on their own right. Just variants of mine. Maybe patched,
> maybe not. Nothing is documented. How does that help anything? How
> should the casual user know which is the official one?
Clojars is a disaster as an authoritative software artifact repository
IMO, and nothing about how it's being used should be taken as a
template for anything else. (Nothing at all against its maintainer(s)
-- the experiment of an open repo was a good one to run.)
As long as you're using more than one segment in your namespaces
(reasons for this discussed here, http://groups.google.com/group/clojure-dev/browse_frm/thread/00b1c6971c3b3394
), I'd say you're fine w.r.t. clashes. A slight caveat to that is
that foo.core doesn't count as a two-segment namespace, insofar as
core is too widespread to provide any kind of uniqueness. (cemerick|
snowtide|weavejester|whatever).foo is perfectly reasonable in almost
all cases. The com.company.foo approach is almost always unnecessary
and undesirable, but discretion and good judgement is always the best
guideline for deciding among all the possible alternatives.
And yes, no matter what you choose, you might end up changing
namespace/package names in the future (or, simply using old namespace
names corresponding to defunct company/product/domain/etc names).
Trying to avoid that is futile IMO, and just a little silly insofar as
such changes aren't the hardest thing to deal with by a large margin,
either from an author's or a user's perspective.
- Chas
Pedro Henriques dos Santos Teixeira
Since there's a lot of forking going on (I've had recently to validate
3 different forks of congomongo, for example), should forks change
their namespace, or just the jar name?
Relying on a single name (i.e. namespace) is suboptimal to resolve this issue.
I think .NET's namespace convention are much more sensible, but relies
on Assembly's metadata to avoid jar/dll hell and forgery.
Ideally the namespace could be whatever you want, and we could think
towards OSGI (or any similar in JVM space) to export proper full name,
version and perhaps in the future even signing the jar.
(regards)
Pedro
Phil Hagelberg
>> So maybe it's best to use the Java convention after all?
>> It has been proven to scale, is widely used and plays well with
>> whatever else is running on the JVM, which are strong points in its
>> favor.
>
> I still don't buy it. The company I work for changed its domain over 4
> years from contiteves.com over contiautomative.com to continental-
> corporation.com and maybe its soon schaeffler-continental-automotive-
> group.com or whatever. Should I always touch each and every code
> module to fix the package names?
On top of that, I've taken over maintenance of several projects, some
of which were started by people who don't even use Clojure anymore.
Luckily they didn't use the com.my.domain namespace convention.
Projects outlive peoples' interest in them, and they certainly outlive
domain registration periods.
> Just to understand the problem (honest questions; I don't know the
> answers): How many open source projects are out there, which have the
> same names? Is a clash in project names, that likely?
Here's what I do: pick good project names[1]. Seriously. Spend some
time thinking it through to find a word that's unique and still
distinctive. This can be hard (naming *is* one of the two remaining
difficult problems in Computer Science), but it's worth doing for
other reasons anyway. Do your homework to ensure that nobody else is
using that name. If some other project comes along later and clashes,
that's their fault, and it can be resolved at clash time.
-Phil
[1] - The one time I didn't do that was with clojure-http-client, and
I ended up getting bitten by an unexpected feature (since disabled) in
Clojure 1.2 that prevented all my functions from being rebound.
(http://www.assembla.com/spaces/clojure/tickets/271-determine-direct-binding-policy-and-controls)
Armando Blancas
Mike Meyer
Phil Hagelberg <ph...@hagelb.org> wrote:
> On Thu, Jul 8, 2010 at 7:15 AM, Meikel Brandmeyer <m...@kotka.de> wrote:
> >> So maybe it's best to use the Java convention after all?
> >> It has been proven to scale, is widely used and plays well with
> >> whatever else is running on the JVM, which are strong points in its
> >> favor.
> >
> > I still don't buy it. The company I work for changed its domain over 4
> > years from contiteves.com over contiautomative.com to continental-
> > corporation.com and maybe its soon schaeffler-continental-automotive-
> > group.com or whatever. Should I always touch each and every code
> > module to fix the package names?
> p
> On top of that, I've taken over maintenance of several projects, some
> of which were started by people who don't even use Clojure anymore.
> Luckily they didn't use the com.my.domain namespace convention.
> Projects outlive peoples' interest in them, and they certainly outlive
> domain registration periods.
And why would them using the com.my.domain namespace convention make a
difference? Unless they were planning on starting *another* project
by the same name in a JVM-based language, there won't be a clash. And
if they're going to recycle the name, then using a project-based
namespace will cause a clash anyway.
People seem to be confused by the Java namespace convention deriving
names from DNS. They think that the names actually have something to
do with the domains in question. This isn't the case. Quoting the
Java Language Specification "The suggested convention for generating
unique package names is merely a way to piggyback a package naming
convention on top of an existing, widely known unique name registry
instead of having to create a separate registry for package names."
> > Just to understand the problem (honest questions; I don't know the
> > answers): How many open source projects are out there, which have the
> > same names? Is a clash in project names, that likely?
> Here's what I do: pick good project names[1]. Seriously. Spend some
> time thinking it through to find a word that's unique and still
> distinctive. This can be hard (naming *is* one of the two remaining
> difficult problems in Computer Science), but it's worth doing for
> other reasons anyway. Do your homework to ensure that nobody else is
> using that name. If some other project comes along later and clashes,
> that's their fault, and it can be resolved at clash time.
Python does that. After 15 years, things started clashing badly enough
to break critical features in optional libraries.
I'd rather avoid that if can.
Meikel Brandmeyer
Am 08.07.2010 um 18:52 schrieb Mike Meyer:
> People seem to be confused by the Java namespace convention deriving
> names from DNS. They think that the names actually have something to
> do with the domains in question. This isn't the case. Quoting the
> Java Language Specification "The suggested convention for generating
> unique package names is merely a way to piggyback a package naming
> convention on top of an existing, widely known unique name registry
> instead of having to create a separate registry for package names."
Hmm… The maven central guys seem to have a different opinion. There you get the group-id only if you *own* the domain.
As for your earlier question: renaming a project on fork allows easy identitfication of the "official" project. Compare:
vimclojure
frobnicator
hotzenplotz
to
de.kotka.vimclojure
meyers.mike.vimclojure
kasperle.vimclojure
So which is the original vimclojure project?
Sincerely
Meikel
Laurent PETIT
In the java world, there are conventions for naming things. Stick with them.
-> You want to fly under the radar in your enterprise with jars full of clojure sources ? Don't get catched because your lib risks a clash or will not work because some IT people established a strict java security policy concerning the packages from which a class loader is allowed to get bytecode
-> You want to provide a library to the external world, publish it on maven/clojar/ivy/whatever repository where one more zillion libraries will also be available, written in java, in clojure, in groovy, in scala ? Protect your namespace by following the same conventions as most of the other people.
Not every wheel is interesting/good to reinvent. Especially when there are still others soo much interesting, deserving your attention :-) :-)
But concerning the initial concern of the OP: there seems not to be a consensus in the clojure community ... yet ! :-)
Mike Meyer
Meikel Brandmeyer <m...@kotka.de> wrote:
> Hi,
>
> Am 08.07.2010 um 18:52 schrieb Mike Meyer:
>
> > People seem to be confused by the Java namespace convention deriving
> > names from DNS. They think that the names actually have something to
> > do with the domains in question. This isn't the case. Quoting the
> > Java Language Specification "The suggested convention for generating
> > unique package names is merely a way to piggyback a package naming
> > convention on top of an existing, widely known unique name registry
> > instead of having to create a separate registry for package names."
p>
> Hmm… The maven central guys seem to have a different opinion. There you get the group-id only if you *own* the domain.
Personally, I trust the inventors of the convention more than people
running a single project. But that begs two questions: how do they
define "ownership" of a domain, and (the question that launched the
thread) what do they suggest people who don't "own" a domain in their
sense do?
> As for your earlier question: renaming a project on fork allows easy identitfication of the "official" project. Compare:
>
> vimclojure
> frobnicator
> hotzenplotz
>
> to
>
> de.kotka.vimclojure
> meyers.mike.vimclojure
> kasperle.vimclojure
>
> So which is the original vimclojure project?
But the question wasn't about "original", it was about "official". So
yeah, with one I can identify the original "vimclojure". But I can
also identify the original "frobnicator" and "hotzenplotz"
projects. But neither naming scheme tells me anything about their
relationships, or about which, if any, is official.
Armando Blancas
> running a single project. But that begs two questions: how do they
> define "ownership" of a domain,
use it as groupId.
and (the question that launched the
> thread) what do they suggest people who don't "own" a domain in their
> sense do?
should be fine:
<groupId>ant</groupId>
<artifactId>ant</artifactId>
<version>1.6.5</version>
Mike Meyer
"Armando Blancas" <armando...@yahoo.com> wrote:
>> Personally, I trust the inventors of the convention more than people
>> running a single project. But that begs two questions: how do they
>> define "ownership" of a domain,
>
>Sounds like common usage; e.g. as the owner of mired.org you get to
>use it as groupId.
So they wouldn't object if I wanted to use my wordpress or sourceforge domains?
Armando Blancas
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
Mike Meyer
By my reading, they would. A wordpress domain is simply out. A sourceforge project domain would be OK, but not a sourceforge user domain. Even more interesting, the practices of some registrars would prevent anyone registering a domain with them from using it as a groupid, as they put themselves in the whois database instead of the purchaser. The other non- project requirement (a page linking the project to the domain name) is pretty much contrary to the quote from the Java specification.
Jeff Rose
so far with a community that had packages was Ruby, and it was
incredibly simple. Everyone can choose whatever name they like for
their package as long as it isn't up on rubygems yet. I am strongly
in favor of dropping these ridiculous Java naming schemes that not
only waste time and obscure library names, but I think they also have
a kind of selfishness to them. Just because I start a project doesn't
really mean it is appropriate to use my domain for the lifetime of the
project. Would you like to be programming with
com.richhickey.clojure.core all of the time? Not I. This is the open
source world, and I think social components like this are important
for collaboration and community. Ruby (and Gems) had its own issues
regarding packages and versioning, but conflicting names was never a
problem for me. There are a lot of names out there, and since we have
the ability to prefix however we like I don't see any good arguments
for the Java naming scheme besides, "that's the way they do it in
Java." Lets evolve.
I find the whole foo.core thing unfortunate too, because it would
otherwise be nicer to just (:use foo). In my own projects I've
adopted this style though, with the idea that I would like my code to
be usable from other JVM languages in the future. Not sure how
realistic or plausible that really is... So yeah, if the goal is to
reach a consensus on package naming, I vote for the foo.core style.
It works for all libs (AOT or not), and it keeps it clean and simple.
It doesn't always have to be "core" either.
foo.central
foo.essence
foo.api
foo.live
foo.base
-Jeff
j-g-faustus
On Jul 9, 5:58 am, Mike Meyer <mwm-keyword-googlegroups.
> The other non- project requirement (a page linking the project to the domain name) is pretty much contrary to the quote from the Java specification.
"groupId" which identifies the project in a Maven build file.
Sun was piggybacking on URLs to make a naming convention for Java
packages, Maven is piggy-backing on the Java package naming convention
with additional restrictions to make a scheme for unique project IDs
with traceable ownership and licensing.
Although groupId and Java package names tend to resemble each other,
and the description on the Maven page is conflating the two, they are
two different entities and made to solve different problems.
From their FAQ on the same page:
- I have a patched version of the foo project developed at foo.com,
what groupId should I use?
* When you patch / modify a third party project, that patched version
becomes your project and therefore should be distributed under a
groupId you control as any project you would have developed, never
under com.foo. See above considerations about groupId.
I guess Maven wants to be the kind of authoritative software artifact
repository Clojars apparently isn't, judging from the comments in this
thread.
jf
Mike Meyer
Jeff Rose <ros...@gmail.com> wrote:
> I've asked myself this same question 50 times now. My best experience
> so far with a community that had packages was Ruby, and it was
> incredibly simple. Everyone can choose whatever name they like for
> their package as long as it isn't up on rubygems yet. I am strongly
> in favor of dropping these ridiculous Java naming schemes that not
> only waste time and obscure library names, but I think they also have
> a kind of selfishness to them. Just because I start a project doesn't
> really mean it is appropriate to use my domain for the lifetime of the
> project. Would you like to be programming with
> com.richhickey.clojure.core all of the time? Not I. This is the open
> source world, and I think social components like this are important
> for collaboration and community. Ruby (and Gems) had its own issues
> regarding packages and versioning, but conflicting names was never a
> problem for me. There are a lot of names out there, and since we have
> the ability to prefix however we like I don't see any good arguments
> for the Java naming scheme besides, "that's the way they do it in
> Java." Lets evolve.
How have you managed to miss the second half of "that's the way they
do it in Java", which is "and we need to interoperate with other JVM
languages." Like it or not, one of the biggest draws of Clojure is
that it interoperates with Java.
> I find the whole foo.core thing unfortunate too, because it would
> otherwise be nicer to just (:use foo). In my own projects I've
> adopted this style though, with the idea that I would like my code to
> be usable from other JVM languages in the future.
For some people, "like" and "future" aren't acceptable options. It has
to be usable from other JVM languages now.
> Not sure how realistic or plausible that really is...
It's not really either.
At the very least, you need to use a top-level namespace that sets
clojure code apart from the other JVM languages (and then expect
projects for which cross-language usage is important to do it the Java
way anyway). I still suggest "clojure" for that.
Saul Hazledine
> My opinion: no need to create problems when there already are accepted
> solutions.
>
> In the java world, there are conventions for naming things. Stick with them.
>
follow it. However, the java solution does create the following new
problems:
1. It leads to deep directory structures that are horrible to navigate
on the command line (even using tab completion) and when browsing
source code. I just went to github and browsed the new volt-db
library. It uses a java style naming convention and I had to click
through 4 levels of directory to get to some source code.
2. It makes the 'ns' declaration at the top of a source file harder to
read. Instead of seeing easy to recognise libraries such as compojure,
hiccup and ring the person reading has reversed tlds to parse.
Somebody ended up on another thread because they had a typo in their
title. However, I like their solution of libraryname.author.file e.g
compojure.weavejester.api
dynamite.acme-corp
The hard work of finding unique handles/authors is done by vanity
(individual or company).
Also, to add my opinion on the original question that started this
thread, I prefer 'foo.api' to 'foo.core' as it gives a clearer idea of
which namespace should be pulled in by the user.
Saul
Laurent PETIT
Phil Hagelberg
<johannes...@gmail.com> wrote:
> From their FAQ on the same page:
> - I have a patched version of the foo project developed at foo.com,
> what groupId should I use?
> * When you patch / modify a third party project, that patched version
> becomes your project and therefore should be distributed under a
> groupId you control as any project you would have developed, never
> under com.foo. See above considerations about groupId.
>
> I guess Maven wants to be the kind of authoritative software artifact
> repository Clojars apparently isn't, judging from the comments in this
> thread.
Clojars has the exact same policy with regard to modified third-party
libraries, (hence the abundance of org.clojars.$USERNAME groupids) it
just doesn't enforce it with technical means; it relies on its users
to make responsible decisions before uploading. Unfortunately this
trust seems to have been misplaced in a few instances, or perhaps the
documentation just needs to be more forceful.
This would not be a big problem (it's easy to fix manually) except for
the fact that the Clojars maintainer has disappeared. I've tried to
contact him to see if he could allow someone else to have access
(perhaps a Clojure/core member?) but have been unsuccessful. I will
try again though--Clojars is too important to leave it in the hands of
one person.
-Phil
James Reeves
> Clojars is a disaster as an authoritative software artifact repository IMO,
> and nothing about how it's being used should be taken as a template for
> anything else.
Ruby and Rubygems has been using single-segment namespaces for years,
with no major problems. I don't think name clashes are a problem in
practise, because projects tend to have original names.
- James
Mike Meyer
They do if you have a central registry for the project names, which
RubyGems provides. If you don't, then they don't. Python doesn't have
a single central registry (it has one official one, and a couple of
unofficial ones that provide features missing from the original), and
it has problems with namespace collisions. For that matter, I've had a
number of my projects share names with other projects.
Even if clojure had such a central registry, you're still forgetting
that JAVA INTEROP IS A MAJOR DRAW FOR CLOJURE. That means you either
need a central registry that covers all the JVM languages (which we've
already got), or a first-level name that clojure projects share that
distinguishes them from all the other JVM languages.
Paul Moore
> Indeed, foo.api sounds better than foo.core to me, now than I'm exposed to
> that (core sounds more like 'internals'). But still I prefer to have the
> library name at the end of the namespace, it's easier to spot than in the
> middle (e.g. I prefer net.cgrand.parsley to paredit.core)
Is there any benefit to using a name like foo.core (or foo.api) rather
than simply foo (beyond sytlistic considerations, that is)? Leiningen
creates a foo.core source file as part of its new project skeleton,
but I prefer foo. Before I start fighting Leiningen, are there any
pitfalls I'll hit (other than the obvious problems of fighting your
tools...)?
Paul.
j-g-faustus
> Ruby and Rubygems has been using single-segment namespaces for years,
> with no major problems. I don't think name clashes are a problem in
> practise, because projects tend to have original names.
speakers know about 10k words. The universe of possible names is
probably larger, but not infinite.
Ruby apparently has about 14k gems, and the advantage of a central
repository where you can check if a name is in use. They still have
things like AccessControl and access_control as two different
projects.
The JVM doesn't have a central repository, at least 10 to 100 times
more libraries than Ruby, and half a dozen different languages running
on it. What are the chances that people will think up half a million
unique single-segment names?
That said, I would leap at a chance to shorten Java names, even if it
were just to chop off the leading "com" or "org". I'm pretty sure the
Java package naming convention is overkill in many (most?) cases. But
as Laurent said, it may not be worth the trouble to reinvent something
else.
I guess I'll go with Chas' suggestion to "use discretion and sound
judgement" for now :)
jf
Mike Meyer
j-g-faustus <johannes...@gmail.com> wrote:
> That said, I would leap at a chance to shorten Java names, even if it
> were just to chop off the leading "com" or "org".
As the owner of mired.org, but not of mired.com (and I don't know the
registered owner) or .net, or of that domain in any other TLD, I'd have
to call that the worst suggestion so far.
Large companies may regularly register their trademarks in every TLD
with multiple spellings (IUC, the IETF has been threatened with
lawsuits if they create more domains because of this), but small
companies don't. Not much point in keeping any vestige of the Java
convention if you're going to cause organizational collisions right
off the bat.
Saul Hazledine
> > That said, I would leap at a chance to shorten Java names, even if it
> > were just to chop off the leading "com" or "org".
>
> As the owner of mired.org, but not of mired.com (and I don't know the
> registered owner) or .net, or of that domain in any other TLD, I'd have
> to call that the worst suggestion so far.
>
are insignificant. As mentioned before in this discussion, TLDs change
owners anyway so the TLD convention can't be used to definitively
identify an owner. The aim of the convention is to reduce the chances
of library names clashing.
As another suggestion how about clj.handle.library e.g
clj.mired.proclog
clj.weavejester.compojure
clj.acme-corp.dynamite
This separates the clojure namespace from the java one, doesn't tie to
a TLD and reduces the chances of collisions at the library level.
Also, somebody mentioned dropping api/core from the core namespace in
a library. Personally, I'd be happy with that.
Saul
James Reeves
> Is there any benefit to using a name like foo.core (or foo.api) rather
> than simply foo (beyond sytlistic considerations, that is)?
Clojure compiles "foo" to a package-less class called "foo".
"foo.ciore" is compiled to a class called "core" in the package "foo".
Package-less classes are a bit problematic if you want to call them
from another Java package, IIRC. But if your library isn't intended to
be AOT-compiled and used from Java, I don't think it makes a
difference.
- James
Meikel Brandmeyer
Am 09.07.2010 um 18:30 schrieb Laurent PETIT:
> But still I prefer to have the library name at the end of the namespace, it's easier to spot than in the middle (e.g. I prefer net.cgrand.parsley to paredit.core)
Now that is a strange argument. net.cgrand.parsley vs. parsley.api. Why should at the end be easier to spot than at the beginning? In particular because parsley.api just contains relevant information while net.cgrand.parsley contains quite a bit of noise. I consider the origin to be noise in the code. Of course it is a fact with some weight when evaluating a library whether it was written by Christophe. But in the code this is completely of no relevance.
Sincerely
Meikel
Laurent PETIT
I'm not talking about what the prefix should be.
I didn't compare it to the "most relevant part" of the name being in the first segment, but in the middle ^^^
Mike Meyer
"Saul Hazledine" <sha...@gmail.com> wrote:
>On Jul 10, 12:16 am, Mike Meyer <mwm-keyword-googlegroups.
>620...@mired.org> wrote:
>> On Fri, 9 Jul 2010 12:49:05 -0700 (PDT)
>>
>> j-g-faustus <johannes.fries...@gmail.com> wrote:
>> > That said, I would leap at a chance to shorten Java names, even if it
>> > were just to chop off the leading "com" or "org".
>>
>> As the owner of mired.org, but not of mired.com (and I don't know the
>> registered owner) or .net, or of that domain in any other TLD, I'd have
>> to call that the worst suggestion so far.
>>
>But the chances of mired.com bringing out a library called 'proclog'
>are insignificant. As mentioned before in this discussion, TLDs change
>owners anyway so the TLD convention can't be used to definitively
>identify an owner. The aim of the convention is to reduce the chances
>of library names clashing.
Considering that there's already another proclog project, I'm not so sure. But the objection is more that I'd rather use the extra level than share the namespace I'm paying for anyway.
>As another suggestion how about clj.handle.library e.g
>clj.mired.proclog
>clj.weavejester.compojure
>clj.acme-corp.dynamite
Why should I prefer clj.mired, shared with gods knows who over org.mired, shared with nobody?
>This separates the clojure namespace from the java one, doesn't tie to
>a TLD and reduces the chances of collisions at the library level.
I'd say we should avoid TLAs for the TLD, given the IETFs preference for them. Given a clojure registry of some sort, just use clojure and share everything else:
clojure.proclog
clojure.compojure
clojure.dynamite
Or to be really beep-beep about it, I could probably arrange to get com.acme.clj and we could use that as the prefix for things in the registry.
>Also, somebody mentioned dropping api/core from the core namespace in
>a library. Personally, I'd be happy with that.
Sounds like one of the things that comes from Javas class/file requirement. I've got no problem with ignoring that.
Jeff Rose
On Jul 9, 6:22 pm, Mike Meyer <mwm-keyword-googlegroups.
> How have you managed to miss the second half of "that's the way they
> do it in Java", which is "and we need to interoperate with other JVM
> languages." Like it or not, one of the biggest draws of Clojure is
> that it interoperates with Java.
fact I specifically chose to use the two part namespace because it
allows for AOT compilation, and thus access from other JVM languages.
> > I find the whole foo.core thing unfortunate too, because it would
> > otherwise be nicer to just (:use foo). In my own projects I've
> > adopted this style though, with the idea that I would like my code to
> > be usable from other JVM languages in the future.
>
> For some people, "like" and "future" aren't acceptable options. It has
> to be usable from other JVM languages now.
>
> > Not sure how realistic or plausible that really is...
>
> It's not really either.
>
> At the very least, you need to use a top-level namespace that sets
> clojure code apart from the other JVM languages (and then expect
> projects for which cross-language usage is important to do it the Java
> way anyway). I still suggest "clojure" for that.
languages, NOW, so yes it is plausible and realistic. I just don't
see myself or many other people use Clojure libraries from outside
Clojure yet, which is why I stated it the way that I did.
You are spamming the list with arguments for these
completely.useless.names.for.libraries.that.google.will.find.before.you.finish.typing.the.package.name,
yet there are plenty of proofs by existence that this kind of scheme
is not necessary to have a successful language or library community.
The whole world is not going to write Clojure, and we don't need to
prepare for it. This is the kind of enterprisey Java think that
results in everything requiring copious amounts of configuration
rather than just working the simple way by default.
I also disagree with this concept of putting the language in the
package name. One of the benefits of compiling down to a common
runtime is that we don't need to care what language something was
written in. I think this kind of meta-data, along with the domain of
the project, authors, etc., should be associated with the Jar file if
anything, but not splatted on the top of every piece of code that uses
a library.
The issue of changing domain names when using the domain as package
name is much worse than only the maintainer having to do a multi-file
search and replace. It means that every user of the library who wants
to upgrade to the latest version also has to go through their code
renaming packages. This all gets much more complicated and messy when
you incorporate dependency injection, reflection and other forms of
dynamic code where a simple search and replace might not do it.
Renaming packages is really annoying, and another of many reasons not
to include domains in package names.
Another annoyance with these loquacious.package.names is that they
require your source to be stuffed away in a column of useless
directories. Even in an IDE they are annoying because in order to see
the information containing components (right most) of package names
you have to have a really wide package manager panel or deal with side
scrolling. Every time I'm back in Java these things annoy me.
Luckily for us, I think the tide is already rising on this
conversation. Most prominent Clojure libraries are adopting the same
packaging scheme as clojure.core, and we are uploading our libraries
to the wild and crazy, totally uncensored and unmonitored clojars.org,
which is working out great in tandem with lein. Clojars wasn't a
failed experiment, it's the future.
-Jeff
Paul Moore
Ah! I hadn't realised the package/class distinction - a result of my
having no Java background. Thanks for the explanation, I can now
understand the trade-offs better.
Paul
Martin DeMello
>
> As another suggestion how about clj.handle.library e.g
> clj.mired.proclog
> clj.weavejester.compojure
> clj.acme-corp.dynamite
+1
martin
Martin DeMello
<mwm-keyword-goo...@mired.org> wrote:
>>As another suggestion how about clj.handle.library e.g
>>clj.mired.proclog
>>clj.weavejester.compojure
>>clj.acme-corp.dynamite
>
> Why should I prefer clj.mired, shared with gods knows who over org.mired, shared with nobody?
You wouldn't; someone without his own domain, or who didn't want to
tie his project namespace to his domain, might.
martin
Mikhail Kryshen
> I also disagree with this concept of putting the language in the
> package name. One of the benefits of compiling down to a common
> runtime is that we don't need to care what language something was
> written in. I think this kind of meta-data, along with the domain of
> the project, authors, etc., should be associated with the Jar file if
> anything, but not splatted on the top of every piece of code that uses
> a library.
in different languages or a library could be rewritten in a different
language while retaining API compatibility.
> The issue of changing domain names when using the domain as package
> name is much worse than only the maintainer having to do a multi-file
> search and replace.
in JVM.
Also I don't see why one have to rename packages at all. Package name
following the java conventions does not have to correspond to the
registered domain owned by the project maintainer.
From the Java Code Conventions
(http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html):
"The prefix of a unique package name is always written in
all-lowercase ASCII letters and should be one of the top-level
domain names, currently com, edu, gov, mil, net, org, or one of
the English two-letter codes identifying countries as specified
in ISO Standard 3166, 1981.
Subsequent components of the package name vary according to an
organization's own internal naming conventions. Such conventions
might specify that certain directory name components be division,
department, project, machine, or login names."
> Another annoyance with these loquacious.package.names is that they
> require your source to be stuffed away in a column of useless
> directories. Even in an IDE they are annoying because in order to see
> the information containing components (right most) of package names
> you have to have a really wide package manager panel or deal with side
> scrolling. Every time I'm back in Java these things annoy me.
--
Mikhail
Phil Hagelberg
> Luckily for us, I think the tide is already rising on this
> conversation. Most prominent Clojure libraries are adopting the same
> packaging scheme as clojure.core, and we are uploading our libraries
> to the wild and crazy, totally uncensored and unmonitored clojars.org,
> which is working out great in tandem with lein. Clojars wasn't a
> failed experiment, it's the future.
Right, I think we have a consensus of sorts here: if you are worried
for some reason about naming collisions, then by all means use the
verbose reverse domain name. The rest of us will all use the
uncluttered way.
-Phil
Mike Meyer
Jeff Rose <ros...@gmail.com> wrote:
> On Jul 9, 6:22 pm, Mike Meyer <mwm-keyword-googlegroups.
> 620...@mired.org> wrote:
> > How have you managed to miss the second half of "that's the way they
> > do it in Java", which is "and we need to interoperate with other JVM
> > languages." Like it or not, one of the biggest draws of Clojure is
> > that it interoperates with Java.
> Nothing about what I said precludes interoperability with Java. In
> fact I specifically chose to use the two part namespace because it
> allows for AOT compilation, and thus access from other JVM languages.
No, it just ignores the increased possibility of collisions once you
include the Java and other JVM language.
> > > I find the whole foo.core thing unfortunate too, because it would
> > > otherwise be nicer to just (:use foo). In my own projects I've
> > > adopted this style though, with the idea that I would like my code to
> > > be usable from other JVM languages in the future.
> >
> > For some people, "like" and "future" aren't acceptable options. It has
> > to be usable from other JVM languages now.
> >
> > > Not sure how realistic or plausible that really is...
> >
> > It's not really either.
> >
> > At the very least, you need to use a top-level namespace that sets
> > clojure code apart from the other JVM languages (and then expect
> > projects for which cross-language usage is important to do it the Java
> > way anyway). I still suggest "clojure" for that.
>
> Using a two part namespace does enable access from other JVM
> languages, NOW, so yes it is plausible and realistic. I just don't
> see myself or many other people use Clojure libraries from outside
> Clojure yet, which is why I stated it the way that I did.
The problem doesn't just occur for people calling clojure libraries
from outside clojure. Hell, if it were, I wouldn't care - I don't plan
on ever doing that. The problem occurs for people calling libraries
from other languages in Clojure, which happens all the time.
> You are spamming the list with arguments for these
> completely.useless.names.for.libraries.that.google.will.find.before.you.finish.typing.the.package.name,
> yet there are plenty of proofs by existence that this kind of scheme
> is not necessary to have a successful language or library community.
If people would quit repeating arguments that have already been shown
to be wrong, there would be no reason to repeat the refutations. Yes,
there are plenty of proofs by existence that a near free-for-all can
be successful. So what? There are also plenty of proofs that a near
free-for-all can cause name collisions and pain as well - even in
successful languages. In fact, the more successful they are, the more
likely that becomes.
If all you want is a successful language, feel free to ignore any data
that doesn't agree with what you're saying. If you want the
environment to be the best it can be, then you examine both sets of
cases, figure out what's different about them, and try and make sure
clojure has the properties of the first set and not the second. Then
you figure out how clojure is different from the successful cases, and
try and figure out how to compensate. I've been doing that and
proposing alternatives to both the free-for-all and the DNS names all
along.
> The whole world is not going to write Clojure, and we don't need to
> prepare for it. This is the kind of enterprisey Java think that
> results in everything requiring copious amounts of configuration
> rather than just working the simple way by default.
No, but it sure as hell seems like the whole world is writing Java
already, and clojure shares that name space. That's what we have to
deal with.
> I also disagree with this concept of putting the language in the
> package name. One of the benefits of compiling down to a common
> runtime is that we don't need to care what language something was
> written in. I think this kind of meta-data, along with the domain of
> the project, authors, etc., should be associated with the Jar file if
> anything, but not splatted on the top of every piece of code that uses
> a library.
Another one of those oft-repeated wrong arguments. That ain't
meta-data, it's just a name, with no meaning whatsoever. The point of
using the language name as the first part of the namespace isn't to
identify what language the program is written in, it's to pick out
part of an existing namespace convention that isn't likely to be used
by anyone else. It could just as well be pybwher.
> The issue of changing domain names when using the domain as package
> name is much worse than only the maintainer having to do a multi-file
> search and replace. It means that every user of the library who wants
> to upgrade to the latest version also has to go through their code
> renaming packages. This all gets much more complicated and messy when
> you incorporate dependency injection, reflection and other forms of
> dynamic code where a simple search and replace might not do it.
> Renaming packages is really annoying, and another of many reasons not
> to include domains in package names.
No, it's a reason not to rename the package just because the project
and/or author changed domains. Thinking you have to do that is one of
those false arguments people keep on making. The Java spec *says* the
domain in a java class name doesn't have any meaning, they're just
piggy-backing on an existing centralized registry. Any software,
organization or person that imputes a real-world meaning from a
classes full name is making a mistake.
> Another annoyance with these loquacious.package.names is that they
> require your source to be stuffed away in a column of useless
> directories. Even in an IDE they are annoying because in order to see
> the information containing components (right most) of package names
> you have to have a really wide package manager panel or deal with side
> scrolling. Every time I'm back in Java these things annoy me.
True, that sucks. An IDE actually helps, because you can scroll away
the meaningless columns. See
http://www.mired.org/home/mwm/papers/simple-clojure.html for my take
on how to deal with them in a CLI (look for "namespaces" on the page).
> Luckily for us, I think the tide is already rising on this
> conversation. Most prominent Clojure libraries are adopting the same
> packaging scheme as clojure.core, and we are uploading our libraries
> to the wild and crazy, totally uncensored and unmonitored clojars.org,
> which is working out great in tandem with lein. Clojars wasn't a
> failed experiment, it's the future.
Won't be the first time I've been on the losing and right side of a
technical argument at the same time. On the other hand, if Clojars
turns into a central registry of names - that's one the thing the
languages without collision problems have that those with them don't
have. I think it's got to much java infrastruture crap in it - doesn't
seem like there's a way to just download a jar from it.