Clojure Q&A - Recent activity in Protocols

Commented: Should reduce-kv support String?

Mon, 01 Jun 2026 00:49:45 +0000

i agree that it matching nth would be the most consistent.

Commented: satisfies? doesn't work with the new instance-based protocol polymorphism

Tue, 06 Feb 2024 16:08:12 +0000

Ran into this yesterday.

Hypergraphs, via protocols, perhaps extending loom?

Thu, 09 Nov 2023 02:41:39 +0000

I am exploring clojure implementations of hypergraphs (edges can join > 2 nodes)? i've used loom for graphs, and imagine trying to extend it somehow.

either with loom or without, any suggestions how to use PROTOCOLS for these definitions?

thanks for any suggestions. - RIk

Retagged: Allow clojure.core/extend to take a regular map as proto+mmaps parameter (today it's just "kwargs")

Tue, 18 Jul 2023 13:37:19 +0000

Often, when you call clojure.core/extend directly (vs extend-type, extend-proto or inline definitions), that means you have some level of composition that happened upstream to create proto extensions for a type.

To recap today the signature of extend is as follows:

([atype & proto+mmaps])

Meaning when it's called it looks like

(extend t protoA {...} protoB {...})

I am advocating to just changing it to

([atype & {:as proto+mmaps}])

That would allow somebody calling into extend to pass either an "unrolled" map like today, or a regular map to it (leveraging the recent patch from @fogus).

(extend t {protoA {...} protoB {...}}) and (extend t protoA {...} protoB {...}) would be supported.

The alternative today when you have a proto+mmaps that is the result of merging implementations is to do something akin to:

(apply extend t (into [] cat proto+mmaps))

the patch would allow to do things such as:

(extend t (merge proto-impl-a proto-impl-b proto-impl-c ...))

I am happy to provide a patch for this if that's considered to be an acceptable change.

Answer selected: Would it make sense to have a flag to cache protocol implementation lookups?

Mon, 25 Apr 2022 13:48:38 +0000

I think a proposal for a caching scheme would be welcomed. I'll log a ticket as a place to discuss further in a bit.

Looking a bit it seems that there are a couple of tickets that look to address satisfies?, the first being https://clojure.atlassian.net/browse/CLJ-1814 which seems to rely on a solution for https://clojure.atlassian.net/browse/CLJ-2426. Both seem to have quite a bit of discussion around them.

Answer selected: Should extenders also list types that extend a protocol via deftype?

Sun, 27 Mar 2022 14:56:46 +0000

This matches the docstring for extenders - "Returns a collection of the types explicitly extending protocol', I think here "explicitly extending" refers to types that have been extended via extend-type or extend-protocol or extend. The three mechanisms of extension are sometimes referred to as "external" (or "explicit"), "direct" (deftype / defrecord / reify), and "metadata", see https://clojure.org/reference/protocols.

So, not a bug.

Closed: defprotocol doesn't resolve tag classnames

Wed, 02 Feb 2022 21:54:10 +0000

defprotocol doesn't resolve tag classnames, this results in exceptions being thrown when the declared protocol uses as a tag an imported class that is not imported in the namespace that uses it.

user=> (import 'clojure.lang.ISeq) clojure.lang.ISeq user=> (defprotocol p (^ISeq f [_])) p user=> (ns x) nil x=> (defn x [y] (let [z (user/f y)] (inc z))) CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: ISeq, compiling:(NO_SOURCE_PATH:4:33)

Patch: clj-1180-2.patch

Screened by: Alex Miller
- My only hesitancy with this patch is making the tagToClass public and reaching into it from core_deftype - this means that call into the Compiler needs to remain open forever as an api.

Comment edited: When does a metadata protocol extension get chosen?

Mon, 27 Sep 2021 20:51:53 +0000

There seems to be one strange corner case that isn't (explicitly) covered by the docs: a metadata impl does not win if the protocol is directly implemented but the direct impl is not provided.

Clojure 1.10.3
user=> (defrecord MissingDirect [] A)
user.MissingDirect
user=> (foo (with-meta (->MissingDirect) {`foo (fn [_] :meta)}))
Execution error (AbstractMethodError) at user/eval208 (REPL:1).
Receiver class user.MissingDirect does not define or inherit an implementation of the resolved method 'abstract java.lang.Object foo()' of interface user.A.

OTOH, if a metadata impl is missing, it defaults to the extends impl. The current wording of the docs doesn't seem to make this discrepancy obvious (but clearly this is all to preserve the fast path).

Protocol dispatch via interfaces is nondeterministic

Tue, 21 Sep 2021 19:25:07 +0000

If an object is an instance of multiple (unrelated) interfaces that each extend a protocol, the dispatched method will be chosen at random.

(defn reproduce []
  (eval 
    (list 'do
          (list 'ns (gensym))
          '(do (definterface A)
               (definterface B)

               (defprotocol P
                 (a [this]))

               (extend-protocol P
                 A
                 (a [this] :a)
                 B
                 (a [this] :b))
               (a (reify A B))))))

(frequencies
  (repeatedly 100 reproduce))
;=> {:b 52, :a 48}

One solution is to sort interfaces by name before choosing the implementation, so at least the nondeterminism is eliminated. We could go further and also print a warning in this case.

Logged as: https://clojure.atlassian.net/browse/CLJ-2656

Answered: Type annotation on protocol causes runtime casting exception

Mon, 20 Sep 2021 15:12:32 +0000

If you want primitive types, use definterface.

Answered: Changing repl formatting function for a type

Wed, 13 Jan 2021 22:21:16 +0000

You can supply a new print-method / print-dup for clojure.lang.Atom, something like:

(defmethod print-method clojure.lang.Atom [obj ^java.io.Writer w] 
  (.write w "#atom"))

Commented: Better stacktraces for protocol methods

Fri, 13 Nov 2020 02:36:45 +0000

You can name the functions using extend directly already, so that really shouldn't be an issue I believe

Answered: Where does one place a nav function when implementing Navigable protocol?

Wed, 05 Feb 2020 01:15:53 +0000

You would add the metadata containing clojure.datafy/nav as the key (and your nav function as the value) to the collection that would be passed to nav, i.e., the nested maps.

It's worth thinking about the full context tho' (for REBL and other tools that use datafy and nav): you start out with "stuff" that is first datafy'd by those tools to produce "pure data" that can be navigated via get etc and also via nav.

So you go from "stuff" -> datafy -> "pure data" (plus nav metadata).

Then from "pure data" -> get -> "new pure data", or from "pure data" -> nav -> "new stuff corresponding to new pure data".

So you might want to start out with your map supporting datafy metadata so that when REBL etc datafies it, the result is navigable -- and could be augmented with additional keys and/or metadata as part of the datafication for display in REBL etc.

If you start with pure data (with nav metadata), calling datafy on it should be an identity function so you could just add nav metadata to the original map. I personally think it's better to start with datafy metadata (and have the implementation add the nav metadata) so that the stuff -> datafy -> data -> nav -> new-stuff pattern is more explicit. That's the approach I took in clojure.java.jdbc and next.jdbc -- and I blogged about datafy/nav in December 2018.

Commented: What is an order of protocol methods lookup in protocol implementation for types having subclass relationship

Tue, 08 Oct 2019 17:45:37 +0000

Hi, Sean!
HoneySQL is a great, compact and minimal. It's a great *physical* pleasure for me to read and tinker it :)
Also I didn't play with your next.jdbc but it's definitely in my plans.

My task is following:
I need to batch several insert honey sql commands which have same metadata shape (table and columns) into single jdbc/execute! call.
Ex:
1. {:insert-into [:my-table]
    :values [{:col1 "str1"
              :col2 "str2"}]}
2. {:insert-into [:my-table]
    :values [{:col1 "str1"
              :col2 nil}]} <--------- here we have nil value

honey sql gives me:
1. "insert into "my-table" ("col1","col2") VALUES (?, ?)" ["str1" "str2"]
2. "insert into "my-table" ("col1","col2") VALUES (?, NULL)" ["str1"]   <----- NULL is inlined

jdbc/execute! awaits sql and vector of sql-params, so i want to submit one sql-statement and vector of sql-params:
"insert into "my-table" ("col1","col2") VALUES (?, ?)" and [["str1" "str2"] ["str1"]] but to do this i should have same params "layout".

As a result i need to override default honeysql behavior that inlines 'NULL' (and booleans) to hoist them into sql parameters.

Result:

1. "insert into "my-table" ("col1","col2") VALUES (?, ?)" ["str1" "str2"]
2. "insert into "my-table" ("col1","col2") VALUES (?, ?)" ["str1" nil]

Maybe you can advice more accurate way to do.

Commented: Can someone explain the arguments to nav ?

Wed, 11 Sep 2019 02:00:38 +0000

nav is not needed in your example: https://github.com/seancorfield/datafy-nav-example/blob/master/src/datafy_test/alt.clj

That produces the exact same results without implementing nav (because nav's default behavior on a hash map is to just return the value v (which is (get coll k) because that's how you invoke nav in this context).

Commented: How to spot patterns where Protocols and custom types are good fit

Sun, 04 Aug 2019 13:41:02 +0000

Just bought the book today. Very good read indeed, thanks for the sugestion

Answered: Protocol functions fail to find future extensions when assigned to a local or new var