Hi, Am Freitag, 1. Juli 2011 02:34:01 UTC+2 schrieb Chas Emerick: > > 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. >
That's not what I understood. I know about the trade-offs between extend and inline methods. I blogged some time ago about it and voted for extend being the default until speed matters. However Stuart wrote "protocols are a low-level implementation detail". And I don't think that this is reasonable. Take any of the collection functions: get, nth, peek, pop, seq, ... Each is a perfect candidate for a protocol function. Why (and how) would I hide this? I think this is a different question than using extend or inlining. Re-reading Stuart's email, I may have actually misunderstood his second paragraph. Sincerely Meikel -- 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
