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
+1 for clojure :)
--
/ Peter Schuller
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
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
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
>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.
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.
>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.
> 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
> 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.
Why would you ever type that more than once? Just use :as.
> 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.
> 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
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
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)
> 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.
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
> 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.
>> 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?
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.
> 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.
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
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
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.
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.
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.
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
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
>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.
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
+1
martin
You wouldn't; someone without his own domain, or who didn't want to
tie his project namespace to his domain, might.
martin
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
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.