Good Question, I was wondering that too. Interfaces have some problems. Protocol solve some of the Problems and Traits solve some but the do not solve the same. Would be interesting to hear how Protocols solves those problem, why the don't are problems or why the don't need to be solved in Clojure because of whatever reason.
I couldn't use them in practices jet but I really like the idea. On 12 Aug., 19:24, Cameron <cpuls...@gmail.com> wrote: > I've been wondering about this topic recently as well. > > >Often such a function does not need to be part of the contract for > >implementers (i.e. the protocol) at all. > > Stu, (or anybody) I'd like to ask about a variation on this point. How > do you handle the case where you have a general function that works > for every type you'd like to implement a protocol for (thus not > technically needing to be in a protocol), but maybe 1 or 2 of the many > types have more efficient implementations possible? Do you just suck > it up and copy and paste the general function around? Or is there a > better way? Maybe the new case function? > > After reading the docs on clojure.org/protocols, it seemed like you > could just define the general implementation of functions under Object > and then define your specific implementations on the other types, but > this didn't seem to work for me. I would get an error to the effect of > "foo is not defined for Type" > > On Aug 12, 9:51 am, Stuart Halloway <stuart.hallo...@gmail.com> wrote: > > > The other thing that you should consider is that protocols are the contract > > for implementers, not the contract for callers. If you change a contract > > for implementers, then the implementers *must* change. > > > Take your example of a function that has a reasonable default for any > > object. Often such a function does not need to be part of the contract for > > implementers (i.e. the protocol) at all. > > > To make this more concrete, look at how protocols are used in Clojure > > itself. InternalReduce is a contract for implementers, consumers call > > reduce. Ditto for IOFactory: clients don't call it, they call the > > functions reader, writer, etc. instead. > > > Stu > > > > Does this > > > help?:http://fulldisclojure.blogspot.com/2010/08/thoughts-on-protocols.html > > > > And Sean's comment > > > here:http://programming-puzzler.blogspot.com/2010/08/racket-vs-clojure.html > > > > Regards, > > > Shantanu > > > > On Aug 12, 5:46 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote: > > >> Hi, > > > >> 2010/8/12 Matthew <mattp...@gmail.com> > > > >>> Hello all, > > > >>> I've been looking at the new protocol (defprotocol, deftype, > > >>> defrecord, etc) feature in 1.2 and, while I love the core concepts, > > >>> it's been bothering me that there's no apparent way to provide > > >>> *automatic* default implementations for methods on a protocol. > > > >>> I know from reading Rich Hickey's discussions on the design rationale > > >>> [1] and other threads on providing Scala Trait-like behaviour [2] that > > >>> you can choose to mix in a set of defaults when you implement the > > >>> protocol, but it seems important to me that a protocol author be able > > >>> to provide default implementations to enable protocols to evolve. > > >>> Allowing a function body in the defprotocol clause would seem to be > > >>> the obvious way, something like: > > > >>> (defprotocol P > > >>> (foo [x] (default-foo x)) > > >>> (bar-me [x] (bar-me [1 x]) > > >>> [x y])) ; no default implementation > > > >>> As I'm sure most of you know, a key problem with "pure" interface > > >>> features in environments like CORBA, COM, Java, etc has been that you > > >>> can't add new methods to published interfaces: you'd break all > > >>> existing implementations. Hence you see a history of evolving > > >>> interfaces indicated by names like IFoo, IFoo2, IFooEx, etc. In > > >>> contrast, a Scala-like trait system allows you to add a new method > > >>> *and* a default implementation (supposing that makes sense), so old > > >>> clients still work fine. > > > >>> The problem, as I see it, with Clojure protocols is that you would > > >>> have to rely on clients mixing in a set of defaults in order to > > >>> happily extend a "public" protocol. > > > >>> Am I missing something key here? I realise there are some very > > >>> experienced people contributing to Clojure, so am fully expecting to > > >>> be told I've missed something obvious ;) > > > >> Maybe have the library writer do this ? : > > > >> (defprotocol P > > >> (foo [x] (default-foo x)) > > >> (bar-me [x] (bar-me [1 x]) > > >> [x y])) ; no default implementation > > > >> (def *P-defaults* > > >> {:foo default-foo > > >> :bar-me #(bar-me 1 %) }) > > > >> and let the user pick the whole *P-defaults* for its mixins, or just > > >> parts > > >> of it ? (does this make sense ?) > > > >>> Cheers, > > > >>> Matthew. > > > >>> [1]http://groups.google.com/group/clojure/msg/330c230e8dc857a9 > > >>> [2]http://groups.google.com/group/clojure/msg/53228e04db4799a5 > > > >>> -- > > >>> 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<clojure%2bunsubscr...@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 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 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
