This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-10-07
Channels
- # announcements (2)
- # babashka (34)
- # beginners (114)
- # biff (7)
- # calva (16)
- # cider (2)
- # clj-kondo (46)
- # clj-on-windows (14)
- # clojars (13)
- # clojure (33)
- # clojure-europe (17)
- # clojure-nl (2)
- # clojure-norway (8)
- # clojure-spec (3)
- # clojure-uk (3)
- # clojurescript (25)
- # community-development (1)
- # datalevin (1)
- # emacs (53)
- # fulcro (31)
- # gratitude (2)
- # jobs (1)
- # lambdaisland (12)
- # lsp (57)
- # malli (3)
- # nbb (1)
- # off-topic (92)
- # pathom (2)
- # pedestal (2)
- # releases (5)
- # shadow-cljs (25)
- # sql (3)
- # squint (1)
- # testing (6)
- # vim (11)
A question about :extend-via-metadata
. Since satisfies?
returns false
for things that only implement a protocol via metadata, would one do something like (or (satisfies? TheProtocol x) (and (satisfies? IMeta x) (contains? (meta x) 'my-qualified/impl-name)))
or is there a better way?
you can just call meta
on anything so that extra satisfies check is a little redundant
I would say that calling satisfies?
in the first place is probably a code smell and would question why you were doing it?
ah. I thought I had run into issues calling meta
on things that don’t implement it but could just be my failing memory
user=> (meta 42)
nil
user=> (meta "s")
nil
user=>
(in Clojure, at least, not sure about cljs but I'd expect the same)It’s a generic data-structure viewer which allows customizing/overriding views for particular types, so we can’t make any assumptions about what is being passed in
@U050RLRRQ So this check is... where...? Protocols can be extended to Object so that would be the default case where no more specific protocol extension applies.
meta
includes a check on the type (in Clojure) and returns nil
otherwise.
we run values through a list of “viewers”, each of which can either handle the value or “pass” if it does not apply. the viewers can be dynamically rebound
so we can’t only rely on implementing a single protocol as the viewers can take more than just an object’s type to decide whether they handle it or not
if you ask me this check is totally fine. you could skip it if you provide a default implementation, but that only makes sense if you control the full protocol
It was a general question, and I meant catching the exception that would be thrown if there's no implementation and treating it as "welp, seems like it doesn't satisfy the protocol after all".
I'd assume the common case will not have this, so the exception will probably be the common case. but that assumption comes from building shadow-cljs Inspect. which may or may not apply elsewhere 😛
yeah in the vast majority of cases a built-in viewer will be used, eg. inspecting common data structures (a generic map-viewer, list-viewer, etc), or a viewer for a custom type where we don’t need to use a protocol. But in certain cases we may want to view eg. a map differently without changing its value and so putting a viewer in its metadata can work nicely
but if there always is a default viewer then you can just call it? and let the metadata basically override it? so no need to check?
not sure I follow exactly. if I call the. protocol’s fn on something that hasn’t implemented it, it will throw?