On Sun, Jun 17, 2012 at 11:59 AM, Kurt Harriger <kurtharri...@gmail.com> wrote: > That is my point, representations SHOULD be considered implementation > details, because representations change... if you treat them as contracts > your code will break everywhere, if you wrap them with abstractions your > code will only need to change in one place...
Have you watched Stu Halloway's talk about the design of Datomic? Evident Code, at Scale: http://www.infoq.com/presentations/Evident-Code-at-Scale You said earlier in this thread that Clojure is your first Lisp so it's possible (likely?) you don't yet realize how different it is to the languages you're used to. If you watch several of the presentations by Stu Halloway and Rich Hickey and some of the other Clojure/core folks, you should get an appreciation of why data-as-API is reasonable in Clojure, in the same way that interface-as-API is reasonable in Java. It's an immutable contract. It can be operated on by all the standard Clojure functions but it's still a contract. It is not necessarily the representation - it is the API you present to the world. You can change the representation any way you want and if the API does not change (in the same way that an interface wouldn't change in Java), then you continue to present the same data structure to client code, even if it is now a projection of the representation, rather than the representation itself. > I have made several reasoned arguments for getter functions... If you > disagree thats fine. Your arguments are reasoned for Java and its ilk because in those languages, data structures are just representation details - and they are mutable, so they can't possibly be an API. Your arguments are not reasoned for Clojure because data structures cannot be modified by client code - they _can_ be the API, and an API that can be used directly by map / filter / reduce and all the sequence functions and so on. Vincent said: > Well, but if interfaces change? That's the same as data representation > change in clojure. This is the fundamental shift in thinking that immutable data-as-API requires. It's how you get some of the real benefits from Clojure. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
