From octave-maintainers-request at bevo dot che dot wisc dot edu Tue Jan 14 09:06:16 2003
Subject: Re: overloaded functions
From: Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov>
To: David Bateman <David dot Bateman at motorola dot com>
Cc: octave-maintainers at bevo dot che dot wisc dot edu
Date: Tue, 14 Jan 2003 10:06:11 -0500

On Tue, Jan 14, 2003 at 11:54:03AM +0100, David Bateman wrote:
> I kind of like the idea of extending dispatch for multiple arguments.
> Although you'd have to include a preference where the overload is
> valid for ANY or ALL of the arguments of the new type, and have a
> means of arbitrating between multi-arg functions that have arguments
> from two different overloaded types. The fact is I also already need
> this functionality for dispatch, since I overload the filter(b,a,x,si)
> function for my Galois type.

You won't need this for compatibility since unless they've changed things,
matlab dispatches off the first argument.  From the filter page of the
communications toolbox:

   "The vectors b, a, and x must be Galois vectors in the same field"

Which is not to say that it wouldn't useful to dispatch off the complete
type signature.  In cases of conflict we could take them in the
reverse order that the dispatches were specified.  We may need to change
the PKG_ADD logic so that the load path is traversed in reverse order
when searching for PKG_ADD otherwise the user may get unexpected results.
Alternatively, if we find a conflict we could pick the function which
is first in the load path, perhaps with an ambiguity warning.  This is
more expensive but it will be less surprising if the user fiddles the
LOADPATH variable a lot.

Paul Kienzle
pkienzle at users dot sf dot net