On Mar 22, 10:54 am, Stuart Halloway <stuart.hallo...@gmail.com> wrote: > >> The questions below refer to the gist > >> athttps://gist.github.com/336674/9ab832a86d203731c6379404d20afded79fe5f5b > >> and to protocols in general: > > >> (1) Clojure automatically types hints the first argument when > >> extending a protocol to an interface or class, which is great. But > >> you cannot override this with your own type hint. Wanting to do > >> this would be very unusual, but see the RandomAccess/List case in > >> the example where one interface signifies the performance > >> characteristics but a different interface has the methods you want. > >> Should it be possible to override the type hint? > > > No. Your wanting to do this is a hint that extending the protocol to > > RandomAccess is not quite right. > > Can you elaborate a little here? I can't extend to List, since I don't > want all Lists, only those that are also RandomAccess. >
You can't do a good job extending this generically (e.g. (-> coll class .newInstance) is reflective and very slow, and not guaranteed to work on all types), so you should only support specific classes. > >> (2) The code for chop is repeated across multiple classes. What is > >> the idiomatic way to DRY this? Should I drop down to using raw > >> extend with maps, or is there more mixin support to come? > > > The idiomatic way is to write an ordinary function, e.g. chop is not > > primitive and can just be written in terms of the protocol. > > I considered this, but thought it would be less discoverable. > Does the > caller care that chop is not primitive? I will argue no. That last bit is what I'm saying, you should choose either a protocol fn or regular fn as appropriate, which one is an implementation detail as far as the caller is concerned. Non-protocol fns might become protocol fns (or be built on same) later on, without affecting clients at all. > The caller > wants, given (say) a String, an easy way to ask "what things can I do > with strings?" I don't see how protocols help you answer that one way or the other. There will always be an open set of non-co-located fns and protocols that might work with String. > Separating protocols from non-primitive functions > creates more places to look. > In fact using protocols to begin with > creates more places to look They are not separated, they are together, both being functions in a namespace. People will find them just as they have always found functions, in namespace documentation. > (right now the string functions all live > in clojure.contrib.string). > Not so. count, seq etc all work with strings and are not in c.c.string > >> (3) The code for slice is also repeated, but only for one arity. > >> Does that change the answer to #2? It's the same answer. Implementing a fn as a protocol fn is an implementation detail of primary interest to extenders. Consumers need only know that foo works on Bars, not how it does so. It will quite often be the case that some nice 10-function API might require the implementation of a 3-function protocol in order to extend it. A protocol is a minimal specification of an abstraction, not a totality of an API. > >> (5) It appears that the overhead for calling a protocol adds a hash > >> lookup (find-protocol-method) over the method invocation itself. Is > >> that the right way to summarize the performance implications? > > > No, since the result is cached. The real every-call overhead is > > having to go through the var to detect changes to the protocol, vs > > the inline-defined case where the implementation of the interface > > can't change given the same instance class. > > Am I saying something different? The cache requires a hash lookup, > right? Only once. There is call-site caching of protocol fns, with no per- call lookup as long as the target class remains the same. Rich -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
