Can we subclass clojure.lang.MultiFn?

[camsaul]

So the usual functions like clojure.core/defmethod and the like can be used. This will make Methodical a true drop-in replacement.

Need to figure out how this will work since clojure.lang.MultiFn is a mutable object and .addMethod actually changes its state, while Methodical multimethods are immutable, so you can only add methods and the like with alter-var-root or equivalent.

Not sure it would actually be possible without reworking Methodical multimethods so they are mutable objects

[acobster]

If I'm understanding correctly, the goal of this is to allow users to use advanced methodical techniques even on multimethods defined upstream in library code out of their control? So for example:

(ns my.project
  (require
    [methodical.core :as m]
    [some.upstream.lib :as lib]))

(m/defmethod lib/vanilla-multimethod :before :default [x]
  (do-stuff x))

Because that would be truly awesome.

Maybe I'm just missing something, but is it possible to accomplish this by delegating to clojure.lang.MultiFn rather than inheriting from it? So in the above example, m/defmethod would detect in some way that lib/vanilla-multimethod is an instance of clojure.lang.MultiFn and call (.addMethod lib/vanilla-multimethod ...) instead of your standard implementation. I believe you could even do this with a protocol that encapsulates only your util fns that map directly on to MultiFn's public methods, such as add-primary-method!:

(defprotocol MethodicalMultiFn
  (add-primary-method! [multifn-var dispatch-val f])
  ...)

(extend-protocol MethodicalMultiFn
  clojure.lang.MultiFn
  (add-primary-method! [multifn-var dispatch-val f]
    (.addMethod (deref multifn-var) dispatch-val f))
  ...

  StandardMultiFn
  (add-primary-method! [multifn-var dispatch-val f]
    ...standard impl...))

I only just started looking at this and don't really understand how auxiliary methods are implemented yet, but in theory as long as your Var -> MethodTable mapping code doesn't care whether the var is a vanilla vs. methodical instance, I think your auxiliary method implementations won't need to change.

[camsaul]

@acobster I'm not sure we'd be able to support aux methods on vanilla multimethods. I was thinking more that we'd let you use clojure.core/defmethod and the like on a Methodical multimethod -- this would let you change your own defmultis to Methodical ones without breaking usage of it.

I think this should be possible, because clojure.lang.MultiFn isn't final: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/MultiFn.java#L18

[camsaul]

For ClojureScript, there's an IMultiFn protocol we could implement https://github.com/clojure/clojurescript/blob/4a73bc8b4c95cfedc614dcabb0fe1795da371d37/src/main/cljs/cljs/core.cljs#L11170-L11179

For JVM Clojure there's no protocol, so we'd have to subclass clojure.lang.MultiFn. I think we'd have to use gen-class, but then it wouldn't work with ClojureScript. So I think we'll need to have separate implementations of StandardMultiFn for Clojure and ClojureScript. Maybe proxy will work, but IIRC that does runtime lookup of methods which would hurt performance

[camsaul]

Don't think gen-class is going to work since we have to AOT it, and that requires all of the protocols it implements to be AOT'ed too... generating our own bytecode with something like insn (wraps ASM) might be our best bet.

[camsaul]

proxy-plus might actually be perfect for this