Re: suggestion for clojure development

[Tal Liron]

On 10/02/2011 01:05 AM, Sean Corfield wrote: Actually I think you're in a better position now. The "new contrib" libraries are all actively maintained and are expected to be compatible with both Clojure 1.2.x and 1.3.0. I'm also hearing a possibility that a "ready-to-go" download of updated contrib libraries will be provided. That seems to address both of your concerns. You're right, it sounds in line with my hopes! Would it be possible to think of a better name for this sister project than "new contrib"? Something that implies its tight relationship with Clojure? I suggest "Clojure Core". It would then be nice to have, perhaps, a less-well-maintained "Clojure Extras" that would be made available for easy use, but without the more stringent guarantees of Core. A library might live in "Clojure Extras" for a while before becoming important enough and achieving the quality standards for moving to Core. So, perhaps a few of us were overreacting to the changes, or the changes were not communicated clearly, or UFOs garbled the transmissions. By the way, the new dev.clojure.org site looks terrific, and is a few orders of magnitude better than the clojure.org site. I can actually get a sense of what's happening in Clojure without joining the Google Group. It's informative. On the other hand, going to clojure.org, I simply see a download link to the new Clojure 1.3.0, with no information on these organizational changes. It's an old complaint, I know, but clojure.org is ... not the most useful web site on the Internet. The UFOs seem to love it, though. But it can be solved by adding ^{:dynamic true} which makes it compatible with both Clojure 1.2.x and 1.3.0. That's how 3rd party libraries are solving this problem and being compatible with both versions. True, but the default behavior was changed to "dynamic false" meaning the libraries *must* be refactored for 1.3.0 in order to even run properly there, which I think was an unfortunate decision. Again, as Arthur suggested, I would have preferred a per-namespace or per-library flag saying "language version 1.3.0" which would have set the default Var behavior to "dynamic false". Unmarked namespaces would have fallen back to the pre-1.3 default of "dynamic true", and a large pain point would have been avoided. Users would have been able to migrate code one namespace at a time, if at all. Water under the bridge at this point, except for when we get to the next bridge. I hope the points raised in this discussion will be taken under consideration. -- 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