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. > > 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. 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 -- 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
