Unexpected behavior with built-in

[David Grundberg]

Jaroslav Hajek skrev:
> On Wed, Jul 22, 2009 at 12:07 PM, John W. Eaton<jwe at octave.org> wrote:
>   
>> On 22-Jul-2009, Jaroslav Hajek wrote:
>>
>> | It's not just feval, but also str2func. Currently, feval(str,...)
>> | works like feval(str2func(str),...), which is OK, but leads to
>> | problems.
>> |
>> | This works OK with 3.2.x:
>> |
>> | function y = my_eval (x)
>> |   y = sin(x) - 0.5;
>> | endfunction
>> |
>> | fzero ("my_eval", 0)
>> |
>> | but watch this seemingly innocent change:
>> |
>> | function y = guarded_eval (x)
>> |   y = sin(x) - 0.5;
>> | endfunction
>> |
>> | fzero ("guarded_eval", 0)
>> |
>> | Surprise! This fails in an incomprehensible way. Your guess is right:
>> | guarded_eval is a subfunction in fzero.
>> | I don't stand by that making feval ignore subfunctions and private
>> | functions is the best solution. Thinking about this, it will actually
>> | bring a lot of trouble for Pytave and other embedded applications of
>> | Octave, which use feval to access functions that may be defined
>> | locally.
>> | But surely Octave should provide a way out of this, even if Matlab
>> | doesn't (does Matlab's str2func ignore subfunctions?).
>>
>> I think the solution is to use function handles and avoid using simple
>> names to refer to functions.  OO methods can cause trouble currently,
>> but I think using function handles should work properly for other
>> cases now.
>>
>>     
>
> In general, yes, handles are better, but still it would be nice if
> str2func had an option to skip the subfunctions and private functions,
> so that you can't exploit subfunctions from outside. This should not
> be a complicated change.
>
> Btw, I'm working on implementing the overloaded handles right now, so
> expect them soon.
>   

The problem is that feval is expected to find subfunctions. In Matlab, 
nested functions cannot be called from feval. So the solution in Matlab 
would be to make guarded_eval a nested function inside fzero.

David