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
Hello,
So far there have been mentions of several techniques :
=> using macro against *db-adapter* :
* will work if *db-adapter* is set at compile-time (in a top level
expression before the macro call, or as a side effect of the invocation of
another macro before the macro call).
* if you AOT-c
James Sofra gmail.com> writes:
>
>
> I know that this has come up before on the group and but is this not
> essentially dependency injection where the dependency being injected
> is a name space that presumably follows a particular convention in
> terms of what functions it provides?
>
> I re
I know that this has come up before on the group and but is this not
essentially dependency injection where the dependency being injected
is a name space that presumably follows a particular convention in
terms of what functions it provides?
I remember people making it pretty clear that they didn
Or, you can go the opposite way and write a macro that expands into the
appropriate ns form. This will work if the information you need from
*db-adapter* is there by macroexpansion time.
A macro that does a similar job to ns, but adds conditional features to the
ns "DSL", can wrap and generalize w
On Mon, Sep 7, 2009 at 1:17 AM, Cliff Wells wrote:
>
> What I've tried (no laughing!) is this bit of code:
>
> (ns site.database
> (:use [compojure])
> (:use [clojure.contrib.sql])
> (:use [site.setup])
>
> (if (= *db-adapter* "mysql")
> (:use [site.adapters.mysql :as adapter]))
> (if (= *
Hi,
I'm new to Clojure (and Lisp-type languages in general) and I've never
used Java... in short, I have a steep learning curve littered with rocks
and nails. I also don't know whether it's a good thing that I have
long experience with Python and C :-P
In any case, as a first project, I'm tryi
16 matches
Mail list logo
