On Jul 23, 10:15 pm, Richard Newman <holyg...@gmail.com> 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 -~----------~----~----~----~------~----~------~--~---
