2009/4/24 AndrewC. <mr.bl...@gmail.com>:
>
>
>
> 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))
As a side note, you can consider shortening your definitions in these
simple cases:
(def fraction-numerator :numerator)
(def fraction-denominator :denominator)
I'm thinking about porting the parts of CL' structure-related macros
(defstruct, etc.) if time permits, since it would make this common
case so much easy while presumably decoupling a little bit client code
from internal code of a lib.
What should be considered so, is how to then make the migration from
"basic" types constructed from that to fully polymorphic and
hierarchized types via defmulti / or mikel gfs.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
