> > Sure, that's the theory behind encapsulation, but I'm not convinced there > are many cases in practice where the API can remain consistent while the > data changes. > > I'm not, either. Models that have little or no abstraction --basically aggregates of related items-- end up having APIs that just reflect their contents. For years, my tools were the Eclipse refactoring features and the code (re)generation of the Eclipse Modeling Framework, not encapsulation. I started using Clojure practices, though not totally convinced until a while ago Stuart Sierra wrote: "The data *is* the API," which helped me understand what I was really doing. Whereas I never faced the proverbial computed-field change, I've now taken good advantage of generic functions over maps and records.
-- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
