On Sunday, June 17, 2012 1:41:22 PM UTC-6, Vinzent 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... >> > > As I mentioned above, this will lead us to objects instead of data. Also, > many people write code without (def foo :foo) and their code isn't breaking > (or at least they are hiding it carefully!), so this statement does not > match the reality, isn't it? > > But I have made this point before and starting to feel like the >> conversation is going in circles. >> > > Yeah, it definitely is. > > I have made several reasoned arguments for getter functions... >> > > Which arguments? We found that :emails is a lazy seq and area is a > function... Could you provide a certain examples where plain maps don't > work, so we could highlight pros and cons and figure out the best way to > work around it? > > >> If you disagree thats fine. But the only well reasoned argument why one >> should not use them except that it adds an extra lines of code to maintain >> and imo LOC is a poor metric for maintainability. >> > > No, the argument is that it replaces data with unstructured objects, > making clojure sequence api inapplicable. Also, it's impossible to use > destructing, pattern matching, testing frameworks functionality and walkers > anymore. Moreover, since clojure doesn't support this approach out of the > box, you'd have to write and maintain some macros in order to avoid > duplication. Generally, I think it can make reading the code more difficult > for other people. >
This is actually the most compelling argument which I didn't give you credit for. However, if you follow the hollywood principle you don't need a seq abstraction. Instead you use pipes and filters and this enables distributing computation across multiple machines without the synchronization bottleneck introduced by list concatenation. Ruby and python make this easy with first class functions and each() blocks. Clojure however might be the worst case, because it requires making seq abstraction part of the contract and in turn creates a dependency on the data structure which in turn creates the need for the getter abstraction in the first place. The need for getters is often an indication that the hollywood principle has been violated, and in clojure this principle is violated more often than it is not in the name of side-effect free functions. Haskell uses monads and this makes functions not only pure but also applies the hollywood principle. I would love to use more Haskell... but I don't think Haskell will ever run on the JVM and even if it ever did the Java libraries would pretty much need to be blacklisted and it wouldn't be all that useful... I thought clojure had potential due to its focus on immutability, but I think the hollywood principle is more important than side-effect free and this was the point of my original reply before we got off topic about abstracting implementation details. If you follow the hollywood principle you don't need getters... but you do need side-effects. It actually seems silly in retrospective to go on and on about the value of getters in OO programs I avoid them like the plauge... but in OO I have the hollywood principle in clojure getters are the only abstraction to protect my code from changes to data representations. -- 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
