Thanks, Logan - that helped indeed! I also saw the compiler warning about that, but wasn't quite sure what to make of it and my solution seemed to work, at least until I tested with zero...
Having said this, I've never seen or heard of a `number` type and found the lowercase naming very misleading until I just browsed once more the source for cljs.core & cljs.analyzer. Is there maybe some more official documentation about this too? Thanks again! K. On 7 June 2014 01:15, Logan Linn <logan.l...@gmail.com> wrote: > It will work for 0 if you use `number` instead of `js/Number`. Generally you > shouldn't extend any js/* type > > On Friday, June 6, 2014 9:57:38 AM UTC-7, Karsten Schmidt wrote: >> >> I'm trying to extend-protocol for numbers and various other types (incl. >> collections & nil) in CLJS, so have been doing something like this (reduced >> email version): >> >> (defprotocol PDeltaEq (delta= [a b])) >> >> (extend-protocol PDeltaEq >> js/Number >> (delta= [a b] :yay) >> >> nil >> (delta= [_ b] (nil? b))) >> >> (delta= 1 1) >> ;; :yay >> >> (delta= 0 0) >> Error: No protocol method Foo.foo defined for type number: 0 >> >> Now I guessed, this might have something to do with JS' considering 0 as >> `false` somewhere in the internal protocol machinery... and I was right! >> Here's a relevant excerpt from the compiled protocol dispatch fn: >> >> var delta_EQ___2 = function(a, b) { >> if (function() { >> var and__3466__auto__ = a; >> if (and__3466__auto__) { >> return a.thi$ng$common$math$core$PDeltaEq$delta_EQ_$arity$2; >> } else { >> return and__3466__auto__; >> } >> }()) { >> return a.thi$ng$common$math$core$PDeltaEq$delta_EQ_$arity$2(a, b); >> } else { >> .... >> } >> }; >> >> Obviously, with the `a` arg being 0, that `if (and__3466__auto__)` check >> is always failing, so shouldn't this check be rewritten as: >> >> if (goog.isDefAndNotNull(and__3466__auto__) && >> a.thi$ng$common$math$core$PDeltaEquals$delta_EQ_$arity$2) { >> return a.thi$ng$common$math$core$PDeltaEquals$delta_EQ_$arity$2; >> } >> ... >> >> This change seems to fix this kind of error and AFAIK doesn't impact any >> of my other (30+) test cases for this protocol... >> >> Thoughts? :) >> >> Thanks, K. > > -- > 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 > --- > 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Karsten Schmidt http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk -- 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 --- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.