Re: Function handles for nonexisting functions

[Judd Storrs]

On Thu, Apr 23, 2009 at 12:20 AM, John W. Eaton <address@hidden> wrote:

That part I don't have a problem with.  It's the part about how and
when the definition can change when the referenced function changes,
and the fact that the rules seem to be different depending on whether
the function is found when the function handle is created, via a
relative or absolute directory lookup.  I don't like all the apparent
special cases.

The simple model that seems to match the behaviour in both versions is
that if the handle is invalid at creation it is always invalid. The
difference between the versions is the evaluation of invalid handles. I
don't think that reproducing the new behaviour exactly in octave is particularly important. 

There are a number of issues with Matlab's new behavior (esp. how function pointers might interact with OOP), and I'm not sure how emulating Matlab's quirks in this domain really matters for octave for this reason -- I suspect that the reason the new behavior was added to Matlab was that it lets users create GUIs with unimplemented callbacks and then run the GUI while incrementally writing the callbacks (avoiding having to restart the GUI after each new callback is written). I could be wrong but I suspect it is very unlikely that intense scoping games are used by Matlab coders.

From your tests, the strange part (to me at least) was when Matlab doesn't realize that the handle was stale if the file wasn't in the current directory or path until you changed directory into that. I think that's probably an optimization related to Matlab cacheing parsed versions of files. Here's another example:

If I create d2/crash.m as before to return 'd2/crash'

function crash ()
'd2/crash'

Then in matlab R2007b (I've shortened the whitespace in the output)

>> cd d2
>> fh = @crash             
fh = @crash
>> fh ()
ans = d2/crash
>> cd ..
Modify d2/crash.m to return 'foo' and return to matlab:
>> fh ()
ans =d2/crash

This is what we saw before. Now I'll show you that the behavior is different if you don't evaluate fh before changing directories. Ok, now reset d2/crash.m to 'd2/creash' and restart Matlab

>> cd d2
>> fh = @crash
fh = @crash
>> cd ..
Modify d2/crash.m to return 'foo' and return to matlab:
>> fh ()
ans = foo
Modify d2/crash.m to return 'bar' and return to matlab:
>> fh ()
ans = foo

So fh kept it's definition at first use. Is that because that was the first time crash was evaluated?

Reset d2/crash.m to 'd2/crash' and restart Matlab

>> cd d2
>> fh = @crash
fh = @crash
>> crash
ans = d2/crash
>> cd ..
Modify d2/crash.m to return 'foo' and return to matlab:
>> fh ()
ans =d2/crash

So it's really Matlab's memory of d2/crash that's driving the behavior and Matlab doesn't notice that d2/crash changes unless it's in the path or current directory. 

--judd