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.
