This is an unfortunate ugly side effect of def and def-like forms being,
um, side effectual.
In the particular case of defmethod, I think that the general
recommendation would be to structure your namespaces such that methods are
defined along side the code that could produce dispatch values which would
trigger those methods. For example, if you were to dispatch by :some-key,
then the functions that produce maps with {:some-key :foo} should be in the
same namespace as (defmethod f :foo ...)
On Thursday, May 9, 2013 5:19:40 PM UTC-4, sdegutis wrote:
>
> In my app, sometimes a file containing a defmethod hasn't been
> required yet by the time some other function calls the multi-method.
> So naturally it throws an exception.
>
> But later, as the app continues to run, the file containing the proper
> defmethod eventually gets required by another file. Then everything
> works fine.
>
> The ugly solution is to require all possible implementations of a
> multi-method in the file that calls it. But that feels like it defeats
> the goal of polymorphism, to not have to know about concrete
> implementors of an interface.
>
> Is there a better solution to this kind of race condition?
>
> -Steven
>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
