>> You can no >> longer take a generic approach to information processing. This results >> in an explosion of needless specificity, and a dearth of reuse."
> For this reason, I've always found appealing languages which let you > optionally write getter/setter methods that "hook into" the standard > field access syntax. This lets you start out with your fields public, > and let your clients use the standard field access "interface". > Later, if you realize you need to do something special, you can easily > add a custom getter without breaking your clients. I'd argue that leaky abstractions like getter/setter methods are evil, and a good article (from a Java/imperative perspective) describing why can be found here: http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1 I think that the quote above from Rich is another good description of why getter/setter methods are bad from a functional perspective. -- 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
