function [inc,s]=tst(A)
inc=@incrementA;
s=@showA;
function incrementA(B)
A=A+B;
end
function showA
A,
end
end
%%%%%%%%%%%%%
I know that when the function handles "inc" and "s" are created, these handles contain hidden persistent variables that record the current value of externally scoped variable A. The thing that I didn't expect is that "inc" and "s" share a copy of A, as the following shows
>> [inc,s]=tst(1); %A is set to 1 in both inc and s
>> inc(3) %inc's copy of A is incremented to 4
>> s() %The incrementation is also reflected in s
A =
4
One might have expected A=1, since at the instant s() was created, that was the snapshot value of A.
So, how is this done? Are externally scoped variables always stored as handle objects within function handles?
"As a rule, a variable used or defined within a nested function resides in the workspace of the outermost function that both contains the nested function and accesses that variable. The scope of this variable is then the function to which this workspace belongs, and all functions nested to any level within that function."
I think a careful read of this paragraph will clear up the question.
Yes, but the thing is, when the nested functions are called through handles in the base workspace, the workspace of the "outermost function" no longer exists. In particular, note the passage from the doc,
"However, when you call nestFun using a function handle, only the nested function executes; the outer function, getHandle, does not."
This makes it somewhat unclear what scoping rules apply after the outer function has exited. Empirically, it seems that the same data sharing continues to be in effect, which is nice... I have no complaints if that's the case.
Yes, only the nested function executes, but the scope of the variable is what is at issue. And according to the doc I produced above, this variable is shared by all functions nested at the same level. At least that is how I understand it!
Doc of R2008a says:
"Function Handles and Nested Function Variables
....
Externally scoped variables that are used in nested functions for which a function handle exists are stored within the function handle. So, function handles not only contain information about accessing a function. For nested functions, a function handle also stores the values of any externally scoped variables required to execute the function."
A is a externally scoped variables since it is an input argument of its outer function, tst.
/ per
Incorrect.
> In particular, note the passage from the doc,
>
> "However, when you call nestFun using a function handle, only the nested
> function executes; the outer function, getHandle, does not."
Yes, the nested function executes and the outer function does not -- but the
nested function accesses the copy of the variable that it and the outer
function share.
> This makes it somewhat unclear what scoping rules apply after the outer
> function has exited. Empirically, it seems that the same data sharing
> continues to be in effect, which is nice... I have no complaints if that's
> the case.
Read through this section of the documentation, particularly the example
near the end of the section.
http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f4-39683.html#f4-64094
--
Steve Lord
sl...@mathworks.com
>
> So, how is this done? Are externally scoped variables always stored as handle objects within function handles?
Is might be instructive to use function FUNCTIONS to explore the nested function handle you get. It teach a lot how things is stored internally.
Note that for this very reason, nested functions can manipulate capture variables as if they are static.
Bruno
> > Yes, but the thing is, when the nested functions are called through
> > handles in the base workspace, the workspace of the "outermost function"
> > no longer exists.
>
> Incorrect.
[SNIP]
> > In particular, note the passage from the doc,
> >
> > "However, when you call nestFun using a function handle, only the nested
> > function executes; the outer function, getHandle, does not."
>
> Yes, the nested function executes and the outer function does not -- but the
> nested function accesses the copy of the variable that it and the outer
> function share.
So then the answer to my original question is yes? The workspace shared by two function handles g and h are recorded through a sub-handle object contained in both g and h?