On Sat, 10 Jul 2010 03:42:16 -0700 (PDT) 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. <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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
