On Thu, 8 Jul 2010 07:15:45 -0700 (PDT) Meikel Brandmeyer <[email protected]> wrote:
> Hi, > > On Jul 8, 7:25 am, j-g-faustus <[email protected]> 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. <mike -- Mike Meyer <[email protected]> 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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
