Hi,
I'm currently investigating what's the best way to add support for function handles in classdef: handle to package functions, static class methods and bound instance methods. According to various tests I've requested in Matlab [1], I believe Matlab does not resolve the function handle at creation time, like octave does, but only when the handle is actually used.
In that context, I've been thinking about changing how function handles are represented internally: simply/only store the function name in the handle object, and resolve to a function dynamically when the handle is ()-indexed; the function resolution could then be entirely delegated to the symbol table, and the process would be very similar to how the interpreter looks for functions. This would solve one of the problems I've bee thinking about for quite some time [2].
This change would actually largely simplifies the function handle code, as most of the job would be delegated to the symbol table. For instance octave_fcn_handle::do_multi_index_op would merely consists of calling symbol_table::find_function and then calling do_multi_index_op on the resulting function object.
However, maybe I'm missing an important aspect. So I'm just asking whether anyone see an obvious gotcha I might have missed.
Michael.
[2] With classdef syntax, there's no 1:1 mapping between functions/methods and m-files anymore. You can have methods entirely defined in classdef files, but you will only know them when the classdef file is parsed. This makes it difficult to have something like @meth, where "meth" is a method defined in a not-yet-loaded classdef file.