2015-11-24 4:31 GMT+01:00 William la Forge <laforg...@gmail.com>: > > For me, the winner is avoiding static structures. I am tired of doing > ongoing refactorings interrupted periodically by complete rewrites. Class > hierarchies are the worst--being the largest, they are the least stable. >
I don't think you'll gain much in that regard, by inventing a new way of pre-binding functions to data, a.k.a instantiating objects. The built-in mechanism for this is called clojure.core/partial. Much more can be gained by concentrating on the flow of data. Functions + immutable data are an excellent tool for that. In that image, an "object" would just be a (static) join point in the data-flow graph. Nevertheless, there are legitimate use cases for composing behaviors mixin-style. Clojure directly supports this in the form clojure.core/extend, by which you can define a protocol implementation by a map of functions. 2015-11-24 9:11 GMT+01:00 Colin Yates <colin.ya...@gmail.com>: > > > One man’s complexity is another man’s simplicity and so on. > More like: One man's state is another man's data, isn't it? Seriously though, I'll have to insist that "simple" is an objective term, as opposed to the subjective "easy", hence assignments of simple vs complex should be agreeable. Thanks to Rich Hickey for that interpretation. -- 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/d/optout.
