Clojure Q&A - Recent questions and answers in Protocols

Answered: Should reduce-kv support String?

Fri, 29 May 2026 21:21:22 +0000

Interesting idea! Logged as https://clojure.atlassian.net/browse/CLJ-2956

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

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

Mon, 13 Mar 2023 15:53:49 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2756 (a more general problem description).

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

Mon, 25 Apr 2022 13:32:17 +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.

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

Sat, 26 Mar 2022 16:40:35 +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.

Answered: When does a metadata protocol extension get chosen?

Wed, 22 Sep 2021 20:28:29 +0000

Yes, this is expected.
https://clojure.org/reference/protocols#_extend_via_metadata

This doesn't really impact the caching of methods, just the selection of the method choice to cache.

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"))

Answered: Better stacktraces for protocol methods

Thu, 12 Nov 2020 14:49:02 +0000

Logged at https://clojure.atlassian.net/browse/CLJ-2590

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.

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

Mon, 07 Oct 2019 16:32:42 +0000

The most specific match will be chosen - given Keyword and Object impls, the Keyword one will be selected.

If the most specific match is ambiguous (same concrete type extends two interfaces that are extended), the selected impl is arbitrary and undefined (so you should probably avoid doing that).

From https://clojure.org/reference/protocols:

"if one interface is derived from the other, the more derived is used, else which one is used is unspecified"

Answered: Can someone explain the arguments to nav ?

Mon, 09 Sep 2019 13:50:16 +0000

nav is a generic framework for navigation. Given a "container" (coll) and some selection in that container, "navigate" to that selection. For containers, k makes sense (like maps), for some it's unnecessary and the selection value is sufficient. As a generic framework, both are provided as you might need both to do selection.

As far as what exactly the inputs and the output are, this is a totally contextual answer. nav is a tool that is fit to the purpose at hand so without knowing a particular goal, it's impossible to be specific. You are typically both the caller and implementer (via instance metadata) of nav and the important thing is that they match.

In REBL, nav is used in service of the browse action where you have something selected in the left pane and you "browse" into it. Other uses may do different things (serializing an object graph, whatever).

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

Tue, 30 Jul 2019 15:14:04 +0000

If you want to take a deep dive about polymorphism in clojure, I recommend a book from Paul Stadig - Clojure Polymorphism. https://leanpub.com/clojurepolymorphism

Answered: Cannot implement protocol methods of the same name inline