On Mar 20, 2010, at 3:56 AM, Stuart Halloway wrote:
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.
(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.
(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)
(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.
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.
