Oops not paying attention you are right. Hash map comes first as the
function. Works like a charm.
2009/2/6 Craig Andera
>
> > (methods multifn)
> >
> > Returns a hash-map where the keys are vectors if the dispatch values of
> the
> > multimethods were vectors, weird and cool :)
> > How does on
Hmm, for example, this does not work:
([:spinoza/object :spinoza-example-three/serializable] (methods archive))
I get the following exception:
java.lang.IllegalArgumentException: Key must be integer
even though:
(= [:spinoza/object :spinoza-example-three/serializable] (ffirst (methods
archive)
> (methods multifn)
>
> Returns a hash-map where the keys are vectors if the dispatch values of the
> multimethods were vectors, weird and cool :)
> How does one check for the existence of a key in a hash-map if the key is
> vector? I tried several things and nothing obvious seemed to work.
Vecto
(methods multifn)
Returns a hash-map where the keys are vectors if the dispatch values of the
multimethods were vectors, weird and cool :)
How does one check for the existence of a key in a hash-map if the key is
vector? I tried several things and nothing obvious seemed to work.
Thanks,
David
-
d
> > call methodTable. It seems to me it would pretty simple to expose this
> > field (or a copy of it anyway) so that multimethod reflection can take
> > place.
> > (responds? astruct amultifn)
> >
> > It's seems to me to be a minor change that would add a co
a copy of it anyway) so that multimethod reflection can take
> place.
> (responds? astruct amultifn)
>
> It's seems to me to be a minor change that would add a considerable amount
> of reflective power to multimethods, as well providing support for something
> like who-sp
Looking at the multimethod implementation (MultiFn.java) I noticed that
multimethod keeps an internal persistent map of dispatch values in a field
call methodTable. It seems to me it would pretty simple to expose this
field (or a copy of it anyway) so that multimethod reflection can take
place
