This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (14)
- # asami (1)
- # babashka (116)
- # beginners (45)
- # bristol-clojurians (1)
- # calva (16)
- # clojure (2)
- # clojure-australia (4)
- # clojure-europe (50)
- # clojure-nl (8)
- # clojure-uk (7)
- # clojurescript (16)
- # crux (4)
- # cursive (4)
- # datomic (2)
- # events (1)
- # fulcro (1)
- # helix (2)
- # jobs (1)
- # jobs-rus (1)
- # polylith (2)
- # re-frame (4)
- # reitit (2)
- # rewrite-clj (8)
- # shadow-cljs (11)
I’m using a M1 Air and installed bb through homebrew. I didn’t even notice it wasn’t native 😅
Any idea what this error means exactly?
(require 'lambdaisland.uri) java.lang.IllegalArgumentException: No implementation of method: :getName of protocol: #'sci.impl.vars/HasName found for class: nil [at /home/arne/github/lambdaisland/uri/src/lambdaisland/uri.cljc:12:1]
offending code is here: https://github.com/lambdaisland/uri/blob/main/src/lambdaisland/uri.cljc#L12
@plexus Yes, defrecord in sci currently has the limitation that you cannot implement Java interfaces on it, only Clojure protocols
what a shame, I was hoping lambdaisland/uri would "just work" since it's largely pure clojure
looking at that code I do wonder why I'm implementing
invoke 😅 , that should be default record behavior... and I guess I can also just define a print handler instead of implementing
@plexus you could use
:bb reader conditionals to support the subset of Clojure that sci supports
yeah that's what I was thinking, I think there's a way to do the same stuff that would be simpler and more interoperable anyway
The rules for this: the
:clj branch will be taken, unless there is a
:bb branch preceding it
I was running into the same issue with a parser combinator library which implemented
Comparable on a defrecord. That was the only change I had to make to make it compatible with bb. I can in theory support this, but you can only implement one Java interface at a time, so if you try to do two, like in your example, you're already out again.
the second one is overriding a method on a base class, I guess the same stuff applies?
yeah, it's tricky when it comes to implementing Java stuff. I can "emulate" most stuff but I can't really trick the Java type system.
I had a hack for
reify before which went like this: at compile time, I created multiple reified objects that implemented all subsets of all supported interfaces. At runtime I would choose the most fitting type which would then dispatch to the interpreted implementations. But this didn't work out since you can get a combinatorial explosion of types, e.g. when you have 100 interfaces to support, you can't really do it anymore, since it generates such a huge list.
The other approach I tried was: generate one reify object which implements all supported interfaces. But this didn't work out with
instance? checks, since it would return
true for a lot of stuff you would not expect it to.
So right now you can use
reify with at most one Java interface + any combination of protocols, for this reason.
I could extend that approach to
:tasks, this time by @lee