doesn't really matter what hashing approach is used, as long as it produces a proper hash

if there are multiple impls only one ends up getting used, so should all be fine

extending these by default could be a problem for engines where they don't exist

not sure what the state of support is for either

It does matter, a lot, when two usages of extend-type with different hashing approaches aren't next to each other. Suppose you have

(extend-type js/BigInt
  IHash
  (-hash [this]
    (hash (.toString this 10))))

(def data (into #{}
                (map js/BigInt)
                (range 1000)))

(extend-type js/BigInt
  IHash
  (-hash [this]
    (hash (.toString this 16))))

(dotimes [i 1000]
  (when-not (contains? data (js/BigInt i))
    (js/console.log i)))

Also a very fun thing to discover:

ClojureScript 1.11.60
cljs.user => (extend-type js/BigInt
               IHash
               (-hash [this]
                 (hash (.toString this 10))))
#object[Function]
cljs.user=> (implements? IHash (js/BigInt 1))
true
cljs.user=> (implements? IHash (js/BigInt 0))
false

> extending these by default could be a problem for engines where they don't exist > not sure what the state of support is for either Is there a list of engines that CLJS aims to support or at least not break needlessly? I'd be glad to check.

Ditto. One thing I have anecdotally seen a lot in requests are concerns about whether e.g. Google Closure has polyfills for ES5 and older JS versions. It would be nice to see an official list of JS engines that the ClojureScript team actively tries to support. While this is a huge wish, something like FreeBSD’s architecture support would be nice to have for users and developers, alike. Namely, there are three tiers for support: 1 = supported and tested, 2 = niche or experimental support, 3 = unsupported or dropping support soon. Just off a wild guess, I would assume Rhino or Nashorn would probably be classified as “Tier 3” JS engines whereas V8 and JSCore would probably be “Tier 1". Of course, making this list is too much work. So maybe just a flat list of “supported JS engines” is the best approach here.

And even without such a list, couldn't CLJS simply do something like this?

(when (exists? js/BigInt)
  (extend-type js/BigInt ...))

I suppose it could. or create a common library to collect these and have other libs depend on that instead of making their own.

https://ask.clojure.org/index.php/12806/feature-request-async-await-support-in-cljs

Ah, found the cause of that aforementioned issue with implements? - it passes the last argument as a condition to if(...), which means that it won't work for anything that's false-y in JS.

Wow that seems like it could use a patch. So does implements? Fail with empty vectors and 0 as well?

@p-himik @sritchie09 this is intentional, btw, implements? means you implemented it via deftype/record and it’s something you control

this was added as a performance optimization primarily and should be used only if you know what you are doing

the primary driver for this is dispatches via cond in the core fns where the order is carefully chosen

could this be a bug? happy to provide an issue + fix

cljs.user=> (macroexpand '(clojure.core/and))
Unexpected error (IllegalArgumentException) macroexpanding cljs.core/macroexpand at (<cljs repl>:1:1).
Don't know how to create ISeq from: java.lang.Boolean