Hi, 2009/7/24 pcda...@gmail.com <pcda...@gmail.com>
> > 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. Java tries hard to hide the detail, yes, but it's still possible to use reflection. So it's just (as you stated) a fact of making it easy or difficult. But you should consider that everything you cannot find in the (doc) of functions is not public API. Then it is indeed easier in clojure to do introspection, etc. of datastructures, but clojure is a powerful language, and as Michale Feathers reinstated recently ( http://blog.objectmentor.com/articles/2009/07/13/ending-the-era-of-patronizing-language-design) : "When you can do anything, you have to become more responsible". And I do agree that it will always be a mental barrier for the large adoption of dynamic languages in the industry :-( > > 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 > Interesting articles enlightening how to not break API contracts in libraries, thanks for sharing ! > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
