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

Reply via email to