I have suffered the exact same problem in large projects. Clojure's 
associative style is extremely powerful and simple, together with powerful 
sequence handling functions you could hurt yourself. The fact that it's 
really easy to put together nested maps to represent your models, shouldn't 
be an excuse for lack of abstraction. In particular I have found that the 
Law of Demeter can be applied to a certain degree to nested clojure maps:

(-> car :wheels first :tire :pressure)

This probably lacks abstraction, calling code needs to know every details 
about how to get the pressure starting from a car model. If at some point 
you decide to change your implementation and turn :wheels into a map instead 
of a list/vector, your code is broken.

As always, it's a compromise between easy of use and resilience to change. 
One of the most important things you loose when you use accessor functions 
is map destructuring. 

I'm still learning in my large clojure projects the art of deciding when 
some code is "too short to be true". I'd love to hear other opinions on the 
subject.

-- 
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

Reply via email to