Fork me on GitHub
#clojure-dev
<
2019-05-23
>
pyr12:05:44

In situations where you are using a dependency injection mechanism like component, it can sometimes be cumbersome to take advantage of multi fns, since you have to figure out a way to hand dependencies over to the method being installed

pyr12:05:25

When the input of the multi-method is a map, we often use namespaced keys inside that map to provision components

pyr12:05:38

(which works well)

pyr12:05:03

In other cases, we may have to call .addMethod on the multi directly

pyr12:05:36

Since this involves interop and having to type hint to avoid reflection

pyr12:05:20

I was wondering whether it could be considered to add an add-method function which would essentially be (eliding a few things):

(defn add-method [^clojure.lang.MultiFn multifn dispatchval f] (.addMethod multifn dispatchval f))

alexmiller12:05:30

I don’t understand the use case - can you flesh it out more?

pyr13:05:45

To try to clarify: without resorting to interop, the only way to add a method on a multimethod if with defmethod

pyr13:05:51

which feels like a toplevel construct and expects an fntail

pyr13:05:14

having a way to supply a dispatchvalue and function directly could be useful in some cases

pyr13:05:32

one such case is if you want the method to capture bindings

pyr13:05:52

(add-method some-multi :dispatch-val (bound-fn* f))

vlaaad13:05:57

(defn add-method [multi-fn dispath-value f]
  (.addMethod ^clojure.lang.MultiFn multi-fn dispath-value f))
?

pyr13:05:23

@vlaaad yes, this is what I was pointing to above

vlaaad13:05:39

oh, you arguing it should be in core

pyr13:05:40

not arguing at the moment, rather wondering 🙂

pyr13:05:01

most of the time just talking about it shows why it's not a good idea in the first place

alexmiller13:05:38

I don't understand why defmethod isn't fine?

alexmiller13:05:48

defmethod could just as easily have been called add-method (I think the "def" is really there to signal stateful var-level change, but you're getting that regardless)

pyr13:05:13

@alexmiller I agree that defmethod is fine for use in closures, and my issue is not with the name

pyr13:05:26

rather, the lack of ability to be fed a function instead of an fntail

pyr13:05:38

which makes some things a tad bit more cumbersome

alexmiller13:05:13

can you give an example where that's cumbersome?

pyr13:05:20

restoring bindings

alexmiller13:05:26

that's not an example

alexmiller13:05:38

I mean code :)

pyr13:05:50

ack, let me synthesize something

alexmiller13:05:26

conceptually, I think it would be perfectly fine to have an add-method in core, that defmethod used, but which could be used directly if needed

alexmiller13:05:47

but I want to be compelled that it's needed :)

pyr13:05:09

Switching that over to defmethod is completely feasible but requires a bit more gymnastics

alexmiller13:05:12

would be fine to ticket this. having a more complete example would be helpful particularly as this seems pretty specific to the lifecycle patterns imposed by component

pyr13:05:31

I think the idea generalizes

pyr13:05:45

our frontend people also had very similar hurdles with re-frame

pyr13:05:16

and thanks

dominicm14:05:09

We've discussed this internally, I don't think this is a good idea. Multimethods are global, and component is local. You can run multiple of the same system in parallel. This would prevent you from running tests at the same time as your REPL.

dominicm14:05:44

We have resorted to protocols when we need state, especially now that the metadata form is available.

pyr16:05:46

hmm it seems the body is truncated and I cannot edit

hiredman16:05:17

I think you may have opened an issue with jira cloud support

alexmiller16:05:27

no, that's ours

alexmiller16:05:40

I am still working on the portal for issue filing so you can be a guinea pig :)