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 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, since we'd
> > > need to evaluate the args at runtime for each call. (Possibly we could do
> > > some compile time optimization, but not in a lot of places, alas)
> >
> >Hmmmm.... shouldn't be any worse than a multi-method call.  And it'll
> >only effect those functions with the 'multi' flag.
> 
> 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 it can change at runtime) Granted, it's
> not a huge expense for non-multi-method calls, but it does still
> impose an overhead everywhere.

Can't you do it with a scary polymorphic function object? (Handwaving
starts which could be *completely* off base.) Then you just have to
rely on the 'call_this_function' vtable method to DTRT, which, unless
it's a 'multi' function, will simply do what function calls have
always done. You only have to do the more complex stuff if the
function object is a 'multi' function, in which case it'll have a
different handler in the vtable.

-- 
Piers Cawley
www.iterative-software.com

Reply via email to