Hi David, I would say that this is a problem in any programming language that makes use of an external library. If the public API of a library changes, you're going to need to update the code that acts as a consumer of that library. It's an inherent risk in upgrading without doing proper vetting of the new version of the library.
What I find to be an acceptable solution to this is having a rubygems like package management system (not that rubygems doesn't have it's own problems) that allows you to move between revisions easily. - Jeremy On Thu, Jul 23, 2009 at 10:58 AM, pcda...@gmail.com <pcda...@gmail.com>wrote: > > Hi. > > I'm learning Clojure, and I like a lot what I've seen so far. Thank > you Rich for designing > such a nice langage, and Stuart for writing such a great book! > > I'm a little worried about the pattern matching/destructuring binding > feature though. It > looks very powerful, but also very dangerous. It seems to encourage > people to "peek > inside" the internals of structured values with no restrictions. > > The kind of scenario I'm worrying about is this: > - Alice writes library foo and use a particular way to encode values > (say simple vectors). > She publishes foo v1.0. > - Bob starts using foo, and because it is so simple and convenient, > uses desctucturing > everywhere. > - Alice adds new features to version 1.1 her library, realizes the > simple vectors are not > enough and decides to use hashmaps instead. > - Bob updates to version 1.1 of foo, and some of his code starts to > break, because all the > patterns he's used are now obsolete. He has no other solution than > to audit all his code > to locate (not necessarily a trivial task) and update the > destructuring patterns which > concern foo data. > > Basically the only way I see to avoid this is for Alice to consider > her choices in > encoding part of the published API of the library, and commit to never > change it after > initial publication, which is rather too restrictive. > > I understand that the problem would exist even without destructuring > bindings, but from > reading Stuart's book, it seems their use is encouraged and considered > good style. Coming > from an OO background which puts a strong focus on data encapsulation, > this makes me a > little nervous. > > Languages like Haskell also have pattern matching, but from what I > understand, because > they are strongly and statically typed, incompatible changes are > detected at compile time > so they can easily be found and fixed. > > Am I worrying for nothing? I have not yet written anything serious in > Clojure so perhaps > these problems do not occur in practice. Maybe following some simple > guidelines are enough > to avoid problems? > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
