On Jul 24, 12:23 am, Jeremy Gailor <jer...@infinitecube.com> wrote: > 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.
I understand this, but several things make it more dangerous in Clojure: - there is no way (that I am aware of) to export "opaque" values to users of a library and prevent them from peeking inside and write code which depends on internal structure. This makes even the most minute detail of you data representation choices de facto part of the public API of your library. Every future change becomes a "public API change". - destructuring encourages clients to depend on these details, and encourages library writers not to provide accessor functions (whose implementation can evolve without breaking clients). - in statically typed languages, incompatible API changes can be detected at compile time. Tools can reliably point you to every part of your code that needs to change. No so in Clojure: you will only get strange Java exceptions at runtime when pattern matching fails. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
