2011/7/1 Chas Emerick <cemer...@snowtide.com>: > > 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.
To be honest, i was just trying to "expand on my own current understanding of the 'received wisdom'", 'cause I also (as Brian did) found that this 'wisdom' is currently poorly explained, letting each and every person "extend it to its own fully qualified demonstration". By being explicit about what I have inferred from the condensed bits that are generally served, my intention is to be proven wrong or not, but by means of arguments and more details. And I'm not sure that the 'received wisdom' is just about "inlining protocol methods" vs other more flexible (but less performant) techniques of extending protocols ... -- 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
