hi,
the following patch is a first attempt at implementing overloaded
function handles:
http://hg.savannah.gnu.org/hgweb/octave/rev/cf714e75c656
a short discussion follows:
Matlab docs say that an overloaded handle stores the base function
path (pointer?) as well as overloads for *standard* classes (double,
cell, logical etc.). When arguments contain objects (user classes),
the dispatch is determined by dynamic lookup (as if normally
referenced).
After considering a couple of alternatives, I eventually found this to
be a good compromise - this way the time to construct a function
handle does not grow linearly with the number of existing classes.
Apparently MathWorks are not that dumb guys :). So I used the same
approach. The downside is that handles to all built-in and library
functions are stored as overloaded (even if actually no overload
exists), because you don't know whether user class overloads exist.
This means a certain performance hit, but I have yet to evaluate its
significance.
ov-fcn-handle also distinguishes the case when a handle is constructed
from a non-overloadable function (subfunction, private function, or
class constructor; shortly, anything that has a higher precedence than
class methods) or is an anonymous function handle. In that case the
dynamic dispatch type is not computed.
This mechanism is provided in a standard manner via the
do_multi_index_op and subsref methods. Now the problem is that many
Octave functions actually use a more "hacky" way to call function
handles: they extract the pointer to the function object via
function_value and then pass that to feval (which calls
do_multi_index_op).
For a long time I played with an implementation overloading
octave_function rather than extending octave_fcn_handle, but in the
end it always seemed to be getting clunky, so I eventually dropped it.
I think that the "normal" manner to call a function should be via
subsref or do_multi_index_op. Extracting the function pointer still
works, but simply ignores the overloads.
So the present state is that overloaded function handles work from
m-files, cellfun, bsxfun (I fixed those) and any other compiled
functions using do_multi_index_op directly. Functions using the hacky
method simply ignore overloads, so existing code should work. For some
functions (e.g. quad) overloaded handles make little or no sense, so
it's maybe useless to attempt to fix those. Right now I couldn't find
out what other built-ins needs adjustments, but I suppose time will
tell.
enjoy!
PS. Information has been previously given on this list that overloaded
handles are covered by certain US patents by MathWorks. I leave it to
anyone interested to check whether any patents may apply. Personally,
I care little about that, partly because I disregard software patents
in general, partly because as an EU citizen US patents do not directly
affect me anyway (isn't that selfish thinking? sorry).
As an "expert in the field" (in terms of the relevant lawyer language)
I can say that the implementation was "obvious" in the sense that it
was straightforward once I chose *what* to implement, and I only
borrowed the idea of caching dispatch to built-in classes from
MathWorks (maybe it would occur to me anyway, but I confess that I saw
that on their site). IMHO such abstract ideas are not patentable, not
even in the US.