protocol implementation delegating to protocol extension doesn't compile

[Jim - FooBar();]

let me explain with an example:


;;in some namespace x

(defprotocol IStemmable
(stem [this token] [this token lang])
(getRoot [this token dictionary]))

(defprotocol IDistance
(getDistance [this s1 s2] [this s1 s2 m-weight]))

;;in some namespace y that refers all vars from x

(extend-type String
IStemmable
(stem
([this] (stem this "english"))
([this lang]
(let [stemmer (help/porter-stemmer lang)]
(doto stemmer
(.setCurrent this)
(.stem))
(.getCurrent stemmer))))
(getRoot [this _ dic] (get dic this "NOT-FOUND!"))
IDistance
(getDistance
([this other]
(help/levenshtein-distance* this other)) ;;delegate to helper fn
([this other mismatch-weight]
(help/levenshtein-distance* this other mismatch-weight)))) ;;same
here


(defrecord PorterStemmer [lang input output] ;;COMPILES AND WORKS FINE -
NO PROBLEMS
IStemmable
(stem [_ token]
(stem token lang)) ;;delegate to String for this
(getRoot [_ token dic]
(getRoot token _ dic)))) ;;delegate to String for this


(defrecord LevenshteinDistance [] ;;DOESN'T COMPILE
IDistance
(getDistance [_ s1 s2]
(getDistance s1 s2)) ;;delegate to String for this
(getDistance [_ s1 s2 weight]
(getDistance s1 s2 weight))) ;;and this


trying to load the file results in:

CompilerException java.lang.IllegalArgumentException: No single method:
getDistance of interface: cluja.protocols.IDistance found for function:
getDistance of protocol: IDistance,
compiling:(/media/sorted/uni_stick/cluja/src/cluja/concretions/models.clj:152:3)


What am I doing wrong? I am practically doing the exact same thing for
these 2 protocols. Both of them delegate to the implementations extended
to string. I keep looking at the code and I see nothing wrong! The
'getDistance' with 3 args delegates to the one with 2 and the one with 4
delegates to the one with 3 (from String)...even more confusingly why
one works and the other complains? any ideas/insights?

Jim

[juan.facorro]

Hi Jim:

I think the problem is that you are actually calling the getDistance protocol function with only 2 arguments in the line in bold below:

 

(defrecord LevenshteinDistance [] 

  IDistance 
  (getDistance [_ s1 s2] 

     (getDistance s1 s2))  ;; <- Calling a getDistance function with 2 args

  (getDistance [_ s1 s2 weight] 
     (getDistance s1 s2 weight)))

While in the protocol definition there's only a 3 and 4 arguments declarations for getDistance.

(defprotocol IDistance 

  (getDistance 

    [this s1 s2]            ; 3 args

    [this s1 s2 m-weight])) ; 4 args

You could add a 2 arguments override for the getDistance protocol function and it would work by calling the 2 args implementation added to String, which is actually never registered in the protocol and goes unnoticed for the reason that follows, which I myself found out while experimenting with your code, you can skip it if you like, I just had a little fun investigating some Clojure code :).

When using extend-type, any implementation for a protocol function with a number of args not present in the protocol's declaration doesn't seem to produce any errors or warnings (extend presents the same behavior, which makes sense since extend-type uses it).

(defprotocol SomeProtocol

  (some-function [this x] [this x y]))

     

(defrecord SomeRecord [])

(extend-type SomeRecord

  SomeProtocol 

  (some-function 

    ([_] (println "1-arg"))         ; this is not declared 

    ([_ _ _ _ _] (println "5-arg")) ; this is not declared 

    ([_ x y]

      (some-function x y)))

However, a CompilerException is thrown when implementing a protocol using the defrecord macro, and declaring a non-existing override for the function. I looked a little bit into the code of defrecord and the reason for this seems to be that it ultimately uses deftype which actually creates a class that implements the methods for the Java interface that the protocol defines, the compiler checks in this case if there's any method with the name and arity with the supplied implementation, and throws an exception if it doesn't.

(defprotocol SomeProtocol

  (some-function [this x] [this x y]))

(defrecord SomeRecord []

  SomeProtocol 

  (some-function [_] (println "1-arg")) ; this is not declared 

  (some-function [_ x y] 

    (some-function x y)))

#<CompilerException java.lang.IllegalArgumentException: Can't define method not in interfaces: some_function, compiling: (file.clj)>

This seems to indicate that using extend (or extend-type) vs. deftpye (or defrecord) for implementing a protocol yields two different results, the former registers the function implementations in the protocol using the map supplied and the latter actually creates a class method for the record or type class generated. 

This was not obvious at all to me and I think I even recall reading somewhere (can't remember exactly where and can't find it right now) that the defrecord "inline" implementation was just a convenience form for extend/extend-type, but is it possible that it's actually more performant to use the defrecord/deftpye?

Hope it helps,

Juan

[Jim - FooBar();]

Hi Juan,

I have to admit you're a life saver! You didn't say anything that I did not know but you did make a couple of observations that made me have a closer look on my code...For example you noticed that the protocol extension to String was never registered...That is the real problem here....I was trying to register two 'getDistance' with 2 and 3 args respectively while the protocol only defines arities 3 and 4...I don't really need to add an arity of 2 on the protocol - what I need to do is properly extend the protocol to String so that both arities are registered...then, it's pretty obvious that the record should be like this (see below - notice the ignored 2nd arg when delegating) and everything works as expected! :)

(defrecord LevenshteinDistance []
IDistance
(getDistance [_ s1 s2]

  (getDistance s1 _ s2))       ;;delegate to string for this

(getDistance [_ s1 s2 weight]

  (getDistance s1 _ s2 weight))) ;;delegate to string for this


The fact of the matter is that Clojure code can get so incredibly terse that after a while my eyes hurt! That said, i certainly prefer my eyes hurting than my brain hurting... ;)

thanks again for taking the time to poke around...as I said, your observations were spot on!

cheers,
Jim

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.