On Fri, Aug 7, 2009 at 11:07 AM, Howard Lewis Ship<hls...@gmail.com> wrote: > > Or really work this into core and add :packages to the (ns) macro.
+1 I have been thinking about this recently anyway. Java is too rigid to work something like this into it's syntax, but Clojure could do it. The benefits that I see coming from this would be that you actually could declare OSGi style dependencies in the code. OSGi declares dependencies not on JARs, but on packages (which are then resolved and imported), and uses an optional range notation (in addition to a fixed version). So you could declare something like (ns example (:use clojure.contrib.json.read (1.5 == x)) (:use compojure.html (1.5 <= x < 2.0))) For the version 'function' a macro is probably needed, because I don't know if the OSGi API can resolve versions with a function, it might need some range datastructure, or even an equivalent string "[1.5,2.0)". This approach has the benefit that the code itself expresses, with which versions it's supposed to run (against which versions it was tested. Another benefit is that OSGi tools can actually be used as a resolver (a la ivy/maven), and they can resolve against OSGi repos, or Maven repos. Check "Cooking with Maven and OSGi" http://www.sonatype.com/books/mcookbook/reference/osgi.html The obvious drawback is that you don't know all future versions which it actually might run against. For that to work, there would still have to be a plug into the resolver, so it's possible to override dependencies (maybe in the first file that's loaded for the application you can tell the resolver that he should try to coalesce dependencies if possible, but that for namespace x.y which imports z in version 1.2, the version is actually 2.0 (and this isn't specified in the original code). Whatever module versioning proposal you take that is on the Java Platform, it needs some kind of annotation for the dependencies. In this way, the annotation could be where it's actually necessary (in the code), and not again outside the code, difficult to keep in sync. And keep in mind that this proposal doesn't mean that you have to run inside an OSGi container, or even use OSGi tools for dependency resolution. It just means that it's very compatible if you want to use OSGi, but you can still have the clojure core resolver use Corkscrew, Clod, or whatever we want (it would make sense to keep it plugable though). I would be interested to hear what people think about something along those lines. Whether you can see some benefits coming from this, or if you think that this presents too much of a hassle (I think it can be simplified to just have a single fixed version in the import statement, so you have a simpler version and it doesn't change so much from the status quo). Cheers, Daniel --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
