On Tuesday, October 9, 2012 9:37:20 AM UTC-4, tbc++ wrote:
>
> >> Polyfns are exactly as fast as protocol functions (I am using the same
> >> caching and dispatch code), but they do not generate a Java interface,
> >> and they are slightly simpler to define.
>
> So I guess I have to ask the questio
Tassilo Horn writes:
> But on the other hand, many of my protocols aren't open but merely an
> implementation detail, and they are extended upon only a few java
> classes (many only 2). For those it seems to be more efficient to use
> a plain function explicitly dispatching on type using `instan
David Nolen writes:
Hi David,
>> I think it might be a good idea to discuss why the Java interfaces
>> are created for protocols.
>
> I don't see how polyfns can be as fast as protocol functions that are
> defined inline and thus backed by an Java interface. It has not been
> my experience that
On Tue, Oct 9, 2012 at 9:36 AM, Timothy Baldridge wrote:
>>> Polyfns are exactly as fast as protocol functions (I am using the same
>>> caching and dispatch code), but they do not generate a Java interface,
>>> and they are slightly simpler to define.
>
> I think it might be a good idea to discuss
>> Polyfns are exactly as fast as protocol functions (I am using the same
>> caching and dispatch code), but they do not generate a Java interface,
>> and they are slightly simpler to define.
I think it might be a good idea to discuss why the Java interfaces are
created for protocols.
Before we h
On Tuesday, October 9, 2012 7:24:57 AM UTC-4, Tassilo Horn wrote:
>
> I'm happy to have complemented my questions with at least a bit useful
> feedback and pointers. :-) At least this latter point is a blocker for
> trying to replace my protocols with polyfns right now.
>
Yeah, thanks for the f
Paul Stadig writes:
> Recompiling a polyfn definition 50 times will only end up with a
> dispatch table of one entry. The multiple entries get added when you
> recompile defrecord and defprotocol. When you recompile a defrecord
> form 50 times you get 50 different types which is why the dispatch
On Tue, Oct 9, 2012 at 2:40 AM, Tassilo Horn wrote:
> Ah, so if I change a polyfn for a type X, the new behavior will only be
> available to new X instances, right?
If you change a polyfn implementation for a type X, then the new
behavior will be available to all instances of X, even those create
On Mon, Oct 8, 2012 at 10:46 PM, Frank Siebenlist
wrote:
> Interesting project, although I'm still a little unclear about the
> "convincing" use cases where you would choose polyfn over protocols...
>
> Also, how does the polyfn implementation compare to the clojurescript
> protocol implementati
Paul Stadig writes:
Hi Paul,
thanks for the detailed answer.
> A drawback with polyfns is there's no Java interface that can be
> extended in Java code to participate in the dispatch.
At least currently I don't see a use-case where I'd need to do that.
>> One minor problem I have with the pro
Interesting project, although I'm still a little unclear about the "convincing"
use cases where you would choose polyfn over protocols...
Also, how does the polyfn implementation compare to the clojurescript protocol
implementation?
-FrankS.
On Oct 8, 2012, at 7:17 PM, Paul Stadig wrote:
>
On Monday, October 8, 2012 1:55:50 PM UTC-4, Tassilo Horn wrote:
>
> Paul Stadig > writes:
>
> Hi Paul,
>
> > I created a library for Clojure to do open, single dispatch
> > polymorphism. What does this mean?
> >
> > * A polyfn dispatches on the type of its first argument.
> > * You can add a
Paul Stadig writes:
Hi Paul,
> I created a library for Clojure to do open, single dispatch
> polymorphism. What does this mean?
>
> * A polyfn dispatches on the type of its first argument.
> * You can add an implementation for a new type to an existing polyfn.
> * You can define a new polyfn on
On Mon, Oct 8, 2012 at 11:33 AM, Timothy Baldridge wrote:
>
>>> Define some implementations for specific types.
>>>
>>> (require '[name.stadig.polyfn :refer [defpolyfn]])
>>> (defpolyfn foo Long [exp] (inc exp))
>>> (defpolyfn foo String [exp] "Hello, World!")
>
> I like the idea, but it seems
>> Define some implementations for specific types.
>>
>> (require '[name.stadig.polyfn :refer [defpolyfn]])
>> (defpolyfn foo Long [exp] (inc exp))
>> (defpolyfn foo String [exp] "Hello, World!")
I like the idea, but it seems to go against the pattern set by multi-fns:
(defmulti foo...)
(defme
I created a library for Clojure to do open, single dispatch
polymorphism. What does this mean?
* A polyfn dispatches on the type of its first argument.
* You can add an implementation for a new type to an existing polyfn.
* You can define a new polyfn on an existing type.
Polyfns are exactly as f
16 matches
Mail list logo
