The questions below refer to the gist at https://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.
(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. The caller
wants, given (say) a String, an easy way to ask "what things can I do
with strings?" Separating protocols from non-primitive functions
creates more places to look. In fact using protocols to begin with
creates more places to look (right now the string functions all live
in clojure.contrib.string).
(3) The code for slice is also repeated, but only for one arity.
Does that change the answer to #2?
Here too, the resulting API is just a set of functions. Whether they
come from protocols is irrelevant to the consumer. The slice
function might end up an ordinary function defined in terms of a do-
slice member of the protocol.
(4) Extending to two different interfaces that a single class
implements results in one class winning arbitrarily (e.g.
IPersistentVector/RandomAccess). This should also be a fairly
unusual case, but is there any plan for specifying precedence?
Not yet. Avoid this situation (and you can here, easily)
OK.
(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?
Stu
--
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.
