2009/4/24 Mark Reid <mark.r...@gmail.com>:
>
> Hi,
>
> This is probably digressing a little from the original question but I
> was wondering if using namespaces here is a reasonable thing to do
> when designing ADTs.
>
>> 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))
>
> Couldn't you define the functions like so:
>
> (ns fraction)
>
> (defn make [n d] {:numerator n :denominator d})
> (defn numerator [f] (:numerator f))
> (defn denominator [f] (:denominator f))
>
> And then from outside the namespace call
>
> (def f (fraction/make 1 2))
> (fraction/numerator f) ; => 1
>
> This seems to me to be a fairly clean way to encapsulate an ADT and it
> doesn't cost any more characters than the prefix style of naming
> functions.
>Hi, both approaches look the same to me : they define a way to abstract the way to manipulate structures independently of their internal representation, but they don't invite polymorphism to the party. Much the same as the distinction in common lisp between structures and CLOS. Your approach has an interesting point though: it seems to allow a better "emergent design" experience. Indeed, a classic way to start is with structures, then polymorphism. If each structure has its functions defined (possibly in its own namespace) without prefix, the client code may look like: (ns fraction-client (:use fraction)) (numerator f) (denominator f) ... while with the prefix convention it will look like: (ns fraction-client (:use fraction)) (fraction-numerator f) (fraction-denominator f) And when the time comes to invite polymorphism to the party, you have no client code to change in the first case, and N places to change in the second. -- Laurent --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
