On Sat, 24 Apr 2010 06:51:18 -0700 (PDT) MarkSwanson <mark.swanson...@gmail.com> wrote:
> >> 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 his fundamental assumption - that getter/setters reveal details of the implementation - is wrong. They *can* do that, and possibly in the Java world they normally do do that. But properly used, attributes reveal information about the *state* of the object, not about the implementation. Classic examples would be a queue object with a "length" attribute, or a financial account object with a "balance" attribute. Neither of those attributes reveal information about the implementation of the objects in question. They both reveal information about the state that some client could find useful. They are both values that, if not directly available from the object should be calculated by the object, as calculating the value requires knowledge about the implementation. > I think that the quote above from Rich is another good description of > why getter/setter methods are bad from a functional perspective. Given that your attributes that aren't just random variables from the implementation, but are reasonable things for a client to want to know, then the unattributed inner quote nailed it: languages that don't distinguish between reading the value of an attribute and invoking a zero-argument method - or at least allow you to make the latter look like the former - hide that specificity and encourage reuse. <mike -- Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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
