Having evolved domain models in large Clojure projects over a long time, I've been going back and forth on maps contra accessor functions to opaque objects and I do see some merit in the latter even though they are not idiomatic Clojure.
Basically, the crucial point for me is how well they work with refactoring. Renaming keys is done without compile-time support. I have to search for instances of :old-key and replace them with :key, and also remember to search for old-key if it is used in a key destructuring without the colon. Renaming accessor functions has the benefit of help from the compiler, which will tell me if the function is not defined so I can easily change the client code to use new name. Inside a module, the cost of the idiomatic way is bearable, but in large-scale programs I find it to be a bit on the limit. Essentially, the keys of a collection returned become an implicit contract between the consumers of the function and the function itself that is very hard to change. When I used scripting languages previously my standard response would be to say that the tests will tell you that it is broken, so there is no problem with the lack of compiler support. However, when data is being passed through layers with lazy data structures this calls for a higher level of integration in the tests which in turn has the potential to make them less robust. Despite all that I am still leaning towards the idiomatic way, but I would love to hear other's experiences of growing domain models in large Clojure projects over time and the design styles that favour that. Cheers, Martin -- 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
