Re: overloading functions

[Paul Kienzle]

On Fri, Nov 16, 2001 at 09:20:37PM -0500, address@hidden wrote:
> On Fri, 16 Nov 2001, John W. Eaton wrote:
> > On 16-Nov-2001, Paul Kienzle <address@hidden> wrote:
> >
> > | Matlab decides what function to call based on the type of the
> > | first argument, which can be done reasonably cheaply and
> > | handles the majority of the cases.
> >
> > This kind of design decision is what bugs me about Matlab, I think.
> > "It will work most of the time.  Users won't be too bothered when it
> > fails.  After all, we don't expect anyone to actually notice the
> > inconsistency because it will come up so infrequently."

If you think of it as a method dispatch rather than function overloading
then matlab's approach is pretty clearly mainstream.  The only difference
is that they use method(object,args) rather than object.method(args).

> 
> Here is another idea (with different benifits and problems).
> 
> If a function could install a handler which sits "in front" of
> currently defined functions, much like TSR type device drivers
> did in DOS.
> 
> Example:
> 
>    function y=sum(x)
>    # do sparse sum - overload current sum
>    if is_sparse(x)
>       y= calulate_sparse_sum(x)
>    else
>       give_up_and_go_to_covered_function
>    end
> 
> Here give_up_and_go_to_covered_function would throw
> away any calculations and call the lower layer function.
> 
> Another implementation:
> 
>    function y=sum(x)
>    # do sparse sum - overload current sum
>    if is_sparse(x)
>       y= calulate_sparse_sum(x)
>    else
>       y= feval(__OVERLOADED_FUNCTION__, x);
>    end
> 
> Where __OVERLOADED_FUNCTION__ is dynamically
> defined to call the lower layer function.
> 
> 
> Advantage:
>    Can be done without any OO infrastructure
> 
> Disadvantages:
>    Slower than function lookup
>    Can be inconsistent if multiple overlay functions
>       are loaded in a different order.
> 
> Comments...

To do this you need some way to rename the existing
function and put the new function in its place.
Unfortunately, the symbol table handling code is
rather complex so the answer isn't obvious.

I made an attempt at defining dispatch() such that
  dispatch(f,type,type_f) dispatches to type_f when
    the first arg is of type, otherwise it calls
    the base function f
  dispatch(f,type) removes type_f dispatch
  dispatch(f) lists all the dispatch rules
See attached.  It works for sum, but curiously does
not work for user functions.  Feel free to fix
it since I won't be working on it for a while.
Feel free to extend it to look at multiple parameters
as well.

I am using map<> from STL because I couldn't figure out 
how to instantiate a CHMap<string,string>.  You will need to
make a private version of mkoctfile without
-fno-implicit-templates as suggested by Nimrod Mesika in 
   http://www.octave.org/mailing-lists/help-octave/2000/1036

Paul Kienzle
address@hidden

dispatch.cc
Description: Text document