It may be pragmatic currently but *manually* copying code is a bad solution. Not depending on libraries is not a good solution either. The premise that there are only 3 levels of composition - clojure -> library -> application - I think is wrong, even if it works and is useful in some cases.
Don't depend on things you don't need to. But don't turn this approach into dogma and give up on better answers. I think there are 3 problems here: 1. Possible library* *conflict - this is primarily a *Naming* conflict - i.e. currently you can only have one version because they are named the same. 2. Data incompatibility - this is incompatibility when passing data across interface boundaries. 3. Number of dependency versions - but only if you need to care about size. Library versioning is currently another example of place oriented programming. i.e same global name, different content => problem. Dave On Tuesday, 14 May 2013 22:19:15 UTC+10, Dave Kincaid wrote: > > This thread seems to have gotten way off track and I think that Stuart > made a very important point in the original post that's getting lost. It > would help all of us out if library authors stopped making their libraries > dependent on 10+ other libraries. This issue does have the potential to > really drag on Clojure adoption. Just try to maintain your own local > repository for your projects and you'll see what I mean the first time you > need to add a Clojure dependency. > > On Tuesday, May 14, 2013 4:22:59 AM UTC-5, Phillip Lord wrote: >> >> Stuart Sierra <ma...@stuartsierra.com> writes: >> > On Tue, May 14, 2013 at 3:25 AM, Phil Hagelberg <ph...@hagelb.org> >> wrote: >> > >> >> It's really not difficult to do if you limit yourself to Clojure since >> >> Clojure namespaces are first-class and easy to manipulate at >> >> run-time. We implemneted a prototype of this in under two hours at a >> >> Seajure meeting a while back: >> >> >> >> https://github.com/technomancy/metaverse >> >> >> >> However, it's significantly more difficult to do for arbitrary Java >> >> bytecode. >> >> >> > >> > >> > That's cool, and it will work for the simple case of libraries A and B >> > depending on different versions of C. >> > >> > But it still breaks down in more complex cases: e.g. if I want to share >> > data between A and B using a protocol or type defined in C, and there >> are 2 >> > incompatible versions of C. Even ClassLoaders can't help you there - >> I'm >> > not aware of any solution. >> >> >> Automatically, no, but the solution would be to use something akin to an >> adaptor. The two versions of C would be manipulated to be in different >> namespaces; now you just have two libraries, so the task of plumbing >> them together remains the same. >> >> To be honest, though, this is unlikely; after all, if you are using A >> and B, and they are using C *as a utility*, my feeling is that C >> shouldn't really be in their public interface. If C *is* in their public >> interface, then again, you need adaptors. >> >> Or you can fork A and/or B, fix them to use the same version! >> >> Phil >> > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
