Trait-like behavior with Protocols

[aria42]

Is it possible to have default implementations associated with
functions in a protocol? This is most useful when some protocol
functions are defined in terms of other. For instance,

(defprotocol Span
(start [self])
(stop [self])
(span-length [self]))

Now I know I can just make span-length a function on Span as opposed
to part of the protocol. Is that what one should do?

[Stuart Sierra]

On Feb 8, 6:13 pm, aria42 <ari...@gmail.com> wrote:
> (defprotocol Span
>   (start [self])
>   (stop [self])
>   (span-length [self]))
>
> Now I know I can just make span-length a function on Span as opposed
> to part of the protocol. Is that what one should do?

Yes.

-SS

[Dan Larkin]

Can you show me what this looks like?

Thanks,
Dan

[Meikel Brandmeyer]

Hi,

The last time I checked, it was my understanding the mix-ins are used
for this.

(defprotocol Thing (abc []) (xyz []))

(def AThing {:abc (fn [] ...) :xyz (fn [] ....)})

(deftype Banana ...)

(extend Thing Banana (merge AThing {:abc (fn []...)}))

This would effectively use the "default" implementation of xyz and
provide a custom one for xyz.

But I'm not up-to-date with the protocol stuff.

Sincerely
Meikel

[Jeff Rose]

I think the extend function is made exactly to support the concrete
implementation of protocols. It takes a type, and then any number of
protocol + function map pairs, where keyword names map to functions.
Checkout the protocol docs on assembla and look for extend:

http://www.assembla.com/wiki/show/clojure/Protocols

or read a recent post by Rich where he talks about some of the design
decisions behind these constructs:

http://groups.google.com/group/clojure/msg/330c230e8dc857a9

-Jeff Rose

On Feb 9, 12:13 am, aria42 <ari...@gmail.com> wrote:

[Konrad Hinsen]

I would say "it depends".

I have a similar situation in my multiarray package (http://code.google.com/p/clj-multiarray/). In the multiarray protocol, I have two functions, "shape" and "rank", with the latter being by definition the same as (comp count shape). However, I still have "rank" in the protocol, because for some implementations it is more efficient to compute the rank directly, rather than construct a shape vector just for computing its length afterwards.

In such situations it is useful to provide a default implementation and leave it up to each type to implement a more efficient alternative or not. With extend and the maps that go with it, this is easy to achieve: make a map with the default implementations, and merge this with the type-specific implementations fed to extend.

Konrad.

[aria42]

If this situation is common enough, shouldn't defprotocol support
optional implementations which are implicitly merged?

[Konrad Hinsen]

On 9 Feb 2010, at 22:29, aria42 wrote:

> If this situation is common enough, shouldn't defprotocol support
> optional implementations which are implicitly merged?

Yes, if it is common enough. It's perhaps too early to decide.

Konrad.