Implementation of protocols for MultiFn

[usernolan]

Hi there!

Have been really appreciating Bidi's data-driven approach to routing. I recently ran into something that surprised me, and I'm curious if I've gone astray.

Here's a rough sketch:

(require
  '[bidi.bidi :as bidi]
  '[bidi.ring :as bidi.ring])

(defmulti  route1 ,,,)
(defmethod route1 ,,,)

(def routes
  ["/route1" route1])

(def handler
  (bidi.ring/make-handler routes))

(handler {:uri "/route1" ,,,})
;; => Execution error (IllegalArgumentException) at bidi.bidi/eval7814$fn$G (bidi.cljc:183). No implementation of method: :resolve-handler of protocol: #'bidi.bidi/Matched found for class: clojure.lang.MultiFn

It's easy enough to implement the bidi.bidi/Matched and bidi.ring/Ring protocols for clojure.lang.MultiFn (identical to the Fn implementations):

(extend-protocol bidi/Matched
  clojure.lang.MultiFn
  (resolve-handler [this m] (bidi/succeed this m))
  (unresolve-handler [this m] (when (= this (:handler m)) "")))

(extend-protocol bidi.ring/Ring
  clojure.lang.MultiFn
  (request [f req _] (f req)))

which seems to work as expected. But I'm curious whether this is the idiomatic way of doing this, or if MultiFn isn't supported for some other reason (e.g. CLJS, maintaining bidirectionality, etc., etc.). Mainly just looking for your guidance on the right way to go about doing this.

Thanks!

[SevereOverfl0w]

This seems reasonable. It might even make sense to double check there's not a common ancestor protocol.

[usernolan]

That is a great idea. I looked a bit further into this, and found that extending these protocols to clojure.lang.AFn using the existing clojure.lang.Fn implementations works as expected for MultiFn:

(extend-protocol bidi/Matched
  clojure.lang.AFn
  (resolve-handler [this m] (bidi/succeed this m))
  (unresolve-handler [this m] (when (= this (:handler m)) "")))

(extend-protocol bidi.ring/Ring
  clojure.lang.AFn
  (request [f req _] (f req)))

This approach would obviously extend to regular fns as well. As a consumer (naive outsider perspective, apply as many grains of salt as appropriate 😂), it seems intuitive to treat MultiFn identically to Fn in this case, given the implementations. Doing so would require almost no effort—I'd be happy to submit a PR if the team is open to it.

Otherwise, I don't mind including the extension in each instance of relevant bidi-consuming code. In any case, I really appreciate the extensibility of the design—it has made the library super easy to work with. Thank you! 🙏