On 23 Apr, 17:59, Mark Engelberg <mark.engelb...@gmail.com> wrote:
> Another problem that has already been "solved" by many OO languages is
> that initially it is most convenient to code certain things as
> properties of the object, and somewhere down the line, you may want to
> change property access into a method call. Most newish OO languages
> have some way to do this, so that you don't have to start out making
> oodles of getters and setters to make your API future proof. Timo
> pointed out the other day that if you start out modeling data as a
> map, and eventually want one of those pieces of the map to be
> dynamically computed from other elements, there's no convenient way to
> change this. All client code that uses assoc and get to simply
> retrieve the field from the map must be changed, or the API must use
> explicit getters and setters from the outset.
If client code is using assoc and get then you haven't really started
thinking of your map as a new data type - you're still thinking of it
as a map.
SICP tells us that we should be defining accessor functions
immediately when we create a new data type.
(defn make-fraction [n d] {:numerator n :denominator d})
(defn fraction-numerator [f] (:numerator f))
(defn fraction-denominator [f] (:denominator f))
etc.
In fact it has this exact example:
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_sec_2.1.1
Then you have no problems with client code when your map is no longer
rich enough to represent your data.
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
