James, Much as I love stable code, I suspect that I am not there yet. Fortunately the code involved is still small. The feedback from you and others has been quite helpful. My preference of course is that we can stabilize it soon. :-)
On Tue, Nov 24, 2015 at 11:39 PM, James Reeves <ja...@booleanknot.com> wrote: > On 24 November 2015 at 13:48, William la Forge <laforg...@gmail.com> > wrote: > >> 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. >> > > One of the reasons Rich's definition of complexity appeals to me is > because its a largely objective one. Complexity is a measurement of > interconnectedness. > > When we attach a protocol to a function, we're adding complexity, since > there's now a connection where none existed before. We're essentially > trading some additional complexity for a hopefully greater amount of > functionality. > > This implies that protocols should be used relatively rarely in Clojure, > and my own experience seems to bear that out. In my projects directory, > there are currently 2260 instances of defn, but only 35 instances of > defprotocol. > > >> 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. >> > > I don't understand why you'd want a protocol for that, nor what an > "aggregate" is in this context. My suspicion is that there might be a > simpler way of solving your problem without creating a new programming > structure. > > - 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/7Q7QvlSUGL4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
