On Jun 30, 2011, at 7:38 PM, Meikel Brandmeyer wrote: > Hi, > > Am 01.07.2011 um 00:16 schrieb Laurent PETIT: > >>> On Jun 30, 2011, at 7:54 AM, Stuart Sierra wrote: >>> >>>> Recently the received wisdom has been: protocols are a low-level >>>> implementation detail. Actual APIs should be built with normal functions >>>> that call the protocol methods. >> >> But still, the functions of the protocol(s) the user will extend will >> not be those which will be called in his code. > > I don't buy that. Why should protocol functions not be part of the public API? > > (defprotocol Associative > (get [this k])) > > (extend-protocol Associative > Vector > (get [this idx] ...) > Map > (get [this k] ...)) > > Looks perfectly fine to me. In fact: how do you want to hide the protocol > here? I think the point is that the protocol does not have to comprise the > whole API. It can be perfectly complemented by normal functions. Or it could > be just "internal" in terms of the user side being only normal functions (the > scenario you describe). But I think there are relatively simple use cases > (see above), where it doesn't have to be that way.
But, you'd never do that, right? Each implementation of Vector and Map would have their own idiosyncratic implementations of `get`, and you _want_ (need) that bolted into the deftyped class. Brian was looking to be able to dynamically rebind a protocol fn, which is simply impossible for classes that have inline implementations. The solution in such cases seems to be that such protocol fns should be implemented via extend, which would then allow for any kind of rebinding or HOF action you want. Unless I'm missing something, I'd revise the "received wisdom" to say "inlined protocol methods are a low-level implementation detail". If you want the perf, go for it, but know that you're giving up some of the benefits of vars for instances of classes that have direct impls. That sounds like a perfectly reasonable tradeoff. - Chas -- 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
