Great question and great answers, thank you. Regarding (3), what if want to process various customer order implementations (say, sort them) in a polymorphic way depending just on their total-price? Assuming I do not control the implementations..
Is it ok in this case to define *HasTotalPrice* protocol (or *total-price*multimethod) and code against that? Or is it better to accept a data structure * along with *total-price-fn* function as an additional parameter? * with :*total-price-fn* as a part of the data structure? * with *:total-price* value already computed? Thanks for any hints.. On Thursday, May 3, 2012 8:30:33 AM UTC+12, stuart....@gmail.com wrote: > > I've read in some recent posts that Clorujians prefer data to APIs. I'm > not sure I understand what this means, in practice. When I'm in the early > stages of developing an application, the data structures undergo a great > deal of change. One of the ways, I isolate parts of the code from these > sorts of changes is by writing accessor functions. Maybe this is OO > thinking but it seems to me a wise application of DRY. > > Would these accessor functions be considered an API? If so, why should I > prefer accessing the raw data structure? If not, what is constitutes an > API? > > > (1) You always have to choose a representation for your data. > > (2) Having chosen a data representation, if you make an accessor function > API, you now have two representations. This is the very opposite of DRY. If > you think that the representation implied by the accessor functions is > better/more stable than the data representation, then choose a data > representation like the one implied by your accessor functions. > > (3) If you have helper functions for dealing with a particular > representation, those helpers can and should be separate from the > representation itself. For example, a customer order is some combination of > maps, vectors, etc. totalPrice is never a member function of some > accessor-riddled Order object -- it is instead a plain function that knows > how to navigate a data representation (or, via a la carte polymorphism, > many different representations). > > Cheers, > Stu > > > Stuart Halloway > Clojure/core > http://clojure.com > > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
