A lot of these arguments go away with functional programming. With a functional queue, you might as well store the length as a value attribute because it won't ever change. In some cases I can see the argument for on-demand computation of fields with referentially transparent caching. That's where the delay form comes in. If you're using the delay form to hide a very expensive computation, it's probably good to express that in the interface by requiring explicit forcing, rather than having an innocent-looking map lookup take arbitrary time to execute because it forces the evaluation of a delayed expression.
-Per On Sat, Apr 24, 2010 at 9:39 PM, Mike Meyer <mwm-keyword-googlegroups.620...@mired.org> wrote: > 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 -- 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
