> > 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. -- 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
