At 07:46 AM 9/2/2001 +0100, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > Nope, the cost will be paid on all sub calls. We at least need to
> > check on every sub call to see if there are multiple versions of the
> > functions. (We can't tell at compile time if it's a single or
Damian Conway wrote:
> Ken wrote:
>> The one thing I'm curious about is whether different syntactic
>> conventions affect the dispatcher or whether this is all just
>> sugar for a single dispatch.
>
> Multiple dispatch is certainly not (practically) implementable via single
> dispatch
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 03:06 PM 9/1/2001 -0400, Michael G Schwern wrote:
> >On Sat, Sep 01, 2001 at 01:10:58PM -0400, Dan Sugalski wrote:
> > > At 10:03 PM 8/30/2001 -0400, Michael G Schwern wrote:
> > > >Thinking about what Zhang was saying about multiple-dispatch not bein
# -Original Message-
# From: Ken Fox [mailto:[EMAIL PROTECTED]]
# Sent: Saturday, September 01, 2001 9:44 AM
# To: Me
# Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Michael G Schwern; Dan
# Sugalski
# Subject: Re: Multiple-dispatch on functions
...
# The one thing I'm curious abo
Ken wrote:
> The way to approach this problem is to profile
> Class::MultiMethods and figure out (a) where the hot spots
> are and (b) what core support would help eliminate those
> hot spots.
But please don't do that until I release the next update of C::MM,
which will use a new dis
At 03:43 PM 9/1/2001 -0400, Michael G Schwern wrote:
>On Sat, Sep 01, 2001 at 03:12:17PM -0400, Dan Sugalski wrote:
> > Nope, the cost will be paid on all sub calls. We at least need to check on
> > every sub call to see if there are multiple versions of the functions. (We
> > can't tell at compil
On Sat, Sep 01, 2001 at 03:12:17PM -0400, Dan Sugalski wrote:
> Nope, the cost will be paid on all sub calls. We at least need to check on
> every sub call to see if there are multiple versions of the functions. (We
> can't tell at compile time if it's a single or multi-method sub call, since
>
At 03:06 PM 9/1/2001 -0400, Michael G Schwern wrote:
>On Sat, Sep 01, 2001 at 01:10:58PM -0400, Dan Sugalski wrote:
> > At 10:03 PM 8/30/2001 -0400, Michael G Schwern wrote:
> > >Thinking about what Zhang was saying about multiple-dispatch not being
> > >inherently OO. I think he's sort of right.
On Sat, Sep 01, 2001 at 01:10:58PM -0400, Dan Sugalski wrote:
> At 10:03 PM 8/30/2001 -0400, Michael G Schwern wrote:
> >Thinking about what Zhang was saying about multiple-dispatch not being
> >inherently OO. I think he's sort of right. Multiple-dispatch need
> >not be confined to method lookup
At 10:03 PM 8/30/2001 -0400, Michael G Schwern wrote:
>Thinking about what Zhang was saying about multiple-dispatch not being
>inherently OO. I think he's sort of right. Multiple-dispatch need
>not be confined to method lookups.
There is the potential for a pretty significant cost to this, sinc
At 04:35 PM 8/31/2001 -0500, Me wrote:
>Dan, I don't immediately see how per object/class dispatch
>control helps to make multimethods pluggable.
There's going to be a "method call" entry in the variable's vtable. You
want a different method call method, you change the entry. Probably by
changi
[EMAIL PROTECTED] wrote:
> Dan, I don't immediately see how per object/class dispatch
> control helps to make multimethods pluggable.
The way to approach this problem is to profile
Class::MultiMethods and figure out (a) where the hot spots
are and (b) what core support would help eliminate those
Dan, I don't immediately see how per object/class dispatch
control helps to make multimethods pluggable. Perhaps a
multimethod (a set of methods) is a class/object? Is there
a general mop for dispatch?
More generally:
> Yes. Ordinary subroutine overloading (like that offered by C++)
> certainly
> Thinking about what Zhang was saying about multiple-dispatch not being
> inherently OO. I think he's sort of right. Multiple-dispatch need
> not be confined to method lookups.
True, but that doesn't make it non-OO ;-)
> foo();
> foo($bar);
> foo($baz);
>
14 matches
Mail list logo
