Risks of (over-)using destructuring?
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 -~--~~~~--~~--~--~---
Re: Risks of (over-)using destructuring?
On Jul 24, 12:23 am, Jeremy Gailor 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 -~--~~~~--~~--~--~---
Re: Risks of (over-)using destructuring?
On Jul 23, 10:15 pm, Richard Newman wrote: > > Coming from an OO background which puts a strong focus on data > > encapsulation, > > this makes me a little nervous. > > The same problem exists with OO. Not to the same extent, unless you expose all the internals of your classes (including fields) as public. > For example, maybe you return a > Headers object from a request. A couple of releases down the line you > realize you need to include some additional info, and now your request > method returns a Response, which has a getHeaders method. Clients break. > > Any use of library code that actually looks at the return value is > prone to this. API changes require code changes. At least in Java, such a change as you describe would be detected at compile time and thus easily identified and fixed. Also there's been a lot of accumulated knowledge over the years on how to evolve OO APIs without breaking existing clients [1]. [1] http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
