I don't see how creating MultiFn directly is any less safe than using
defmulti which also creates mutable object. And multimethods are never
pure functions (may return different values for the same argument
after defmethod call). I think the documentation should explicitly
state mutability and non-
You could create a local instance of clojure.lang.MultiFn in a let
binding, and access it directly. You can see the definition of the
object here:
http://github.com/richhickey/clojure/blob/master/src/jvm/clojure/lang/MultiFn.java
The very good reason you DO NOT DO THIS is that this object is
MUT
2010/5/17 Mikhail Kryshen :
> On 17 май, 12:07, Laurent PETIT wrote:
>> Yes,
>>
>> as David wrote,
>>
>> What you're describing is not single-dispatch-based polymorphism (e.g.
>> like in java), it's double dispatch (because you want to dispatch to
>> the implementation of the protocol function bas
On 17 май, 12:07, Laurent PETIT wrote:
> Yes,
>
> as David wrote,
>
> What you're describing is not single-dispatch-based polymorphism (e.g.
> like in java), it's double dispatch (because you want to dispatch to
> the implementation of the protocol function based on both the type and
> another par
Yes,
as David wrote,
What you're describing is not single-dispatch-based polymorphism (e.g.
like in java), it's double dispatch (because you want to dispatch to
the implementation of the protocol function based on both the type and
another parameter which may be totally dynamic, or materialized -
On Saturday, May 15, 2010, Mikhail Kryshen
> set of extenders and implementing functions. This state (what
> types currently implement the protocol and how) is what I really
> want to be able to manipulate. The way it is tied to the protocol
> definition and changed by the extend function seems to
On 16 май, 05:57, ataggart wrote:
> Perhaps you misunderstand protocols. Protocols don't support a
> hierarchy, thus you don't extend them; you have types implement/reify
> them. Any "extending" you do will be against a type.
By extending the protocol I mean "extending the polymorphism of
the p
On 16 май, 05:57, ataggart wrote:
> Perhaps you misunderstand protocols. Protocols don't support a
> hierarchy, thus you don't extend them; you have types implement/reify
> them. Any "extending" you do will be against a type.
By extending the protocol I mean "extending the polymorphism of
the p
dds state
> (current set of extenders and corresponding implementations) and
> extend function does not modify the protocol structure itself nor does
> it return new version of it but changes the state elsewhere. This
> makes dynamic use of protocols (e.g. having functions that crea
es
it return new version of it but changes the state elsewhere. This
makes dynamic use of protocols (e.g. having functions that create,
accept or return protocols) problematic.
Also it may be useful to have with-protocol macro that will bind
function vars to the implementations associated wit
10 matches
Mail list logo
