Re: Too many arguments?

[Olaf Till]

On Thu, Aug 06, 2009 at 11:39:27AM +0200, Carlo de Falco wrote:
>
> On 6 Aug 2009, at 10:16, Olaf Till wrote:
>
>> On Wed, Aug 05, 2009 at 10:23:22PM -0400, John W. Eaton wrote:
>>> I don't remember exactly why I chose to make Octave silently accept
>>> extra arguments.  Maybe I didn't have an easy way to implement this
>>> feature at the time.
>>>
>>> In any case, some people might think this difference with Matlab is a
>>> minor bug.  It would probably not be hard to make Octave generate an
>>> error in this case, so it might happen in the future.  If you don't
>>> want that, then can you explain clearly why it makes sense for Octave
>>> to silently accept extra arguments that are not used?
>>
>> Because then a function can be called with some extra last arguments,
>> no matter whether the called function has listed them in its
>> header. This makes sense if it can vary which function is called,
>> e.g. if the function to be called is configurable. If extra arguments
>> do not cause an error, one can change the interface of the function
>> call at the caller side without changing each existing called
>> function.
>>
>> Example: In Octave-Forge, for main/optim/leasqr.m the user has to
>> supply a user-function and may supply a second function to compute its
>> Jacobian. If the user doesn't supply the latter, a generic function is
>> used to estimate the Jacobian with difference quotients (dfdp.m). Now
>> I would like to introduce maximal or minimal values for parameter
>> estimation into leasqr.m. These maximal or minimal values should for
>> some reason also be respected by dfdp.m. So I would like to pass an
>> additional argument which contains the maximal or minimal values from
>> leasqr.m to dfdp.m. But users may already have used leasqr.m before
>> with their own Jacobian-functions, which do not have the extra
>> argument in the interface (and BTW probably do not need to honour it
>> anyway, since they do not compute difference quotients). If Octave
>> does not accept extra arguments, these users have to change the
>> interface of their functions after the interface-change in leasqr.m.
>>
>> Olaf
>
> Just my two cents,
> why don't you implement this "backward compatible" behaviour using a  
> try/catch block?
> e.g.:
>
> try
>  user_function (more, arguments, than, expected);
> catch
>  warning (lasterr ());
>  warning ("the interface for user defined functions has changed, see  
> package docs for details");
>  user_function (fewer, arguments);
> end

I thought of that, but the called function again calls another user
function, which can be quite complicated and can cause errors. These
errors would also be caught by the try/catch block. This complicates
their debugging. A solution could be to detect in the catch block
where the error came from and decide what to do. If necessary, all
error messages must be passed to the user (but lasterr does not return
all). I do not think this is feasible.

Olaf