James, thanks for recommending Simple Made Easy <http://www.infoq.com/presentations/Simple-Made-Easy>. As usual, I strongly agree with 95% or more of everything Rich says.
While listening to this talk, I kept thinking about why I am avoiding protocols. In general, I very much like having abstractions. But I find that even small abstractions tend to complect what with how. Protocols are the perspective of the client code. It defines what is there to be used. But they should not be part of the code that provides a service. Rather, they should belong to the aggregate of service providers. Lets look at an example. Suppose we have get and set! functions which an aggregate supports. Normally you would think of get and set! as being implemented by code that implements both. So you define a protocol that has both. It is a small protocol that has nothing else. But it is possible that these are implemented by very different pieces of code within an aggregate. So it dawns on me. I need more code, not less! I should (a) define functions with the aggregate map as the first argument rather than the last and (b) use extend to add these functions to the Map interface. Now I have protocols. Only, there is no type name since all aggregates are maps. So I have not gained anything. OK, so lets use deftype to define a type. It has a single field, which is the aggregate map. And we construct the type by creating that aggregate. AND THEN we extend that type with various protocols as convenient for how we use it. We need code to create specific aggregations anyway, so the only additional code here are the protocols and the extend. These provide the abstractions convenient to the code that wants to use the aggregate. So wow, even more code. Have we accomplished anything??? YES! We have decoupled the abstractions from the implementations. Indeed, we can completely rework our abstractions (which I do a lot) without touching the code that implements them. For me, this is a major win. A substantial decomplection! One question remains then. Is it worth the added code? This is simplification at the cost of easy. Loved that talk, James. :-) -- 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.
