On Fri, 26 Feb 2010, Sven Schreiber wrote:
Riccardo (Jack) Lucchetti schrieb:
> On Thu, 25 Feb 2010, Allin Cottrell wrote:
>> On Thu, 25 Feb 2010, Sven Schreiber wrote:
>>> Allin Cottrell schrieb:
>>>> mwrite(xy, "(a)dotdir/xy.mat")
>>> OT: I know about the return value of mwrite(), but this "feels"
>>> like a command than a function. Or to put it differently: if I
>>> understand correctly you recently introduced more sophisticated error
>>> handling ($error and stuff). I wonder whether a mish-mash is being born
>>> right now, sometimes getting error codes from function return values,
>>> and sometimes from accessor variables?
>> I take your point that mwrite feels more like a command than a
>> function. One reason it was done as a function is so that it could
>> return an error code (rather than just bombing out on failure).
>> Now that we have "catch" (see the manual) that could be
>> reconsidered; but symmetry with mread (which is "naturally" a
>> function) would argue for function status for mwrite.
Yes I think there are two different issues here: one is commands vs.
functions, and the other is how to do error handling. With respect to
the error handling one could argue to have only one way of doing things.
That would raise the question of what functions like mwrite() should
return instead. OTOH I can also see that catch is for commands, and
return values for functions -- but what about those functions that have
natural return values? What I really wouldn't like is to have catch for
commands and *some* functions, and for other functions using the return
value as error code. That I would find confusing.
I'm not sure exactly what should be done here, but I tend to agree
that it would be messy to have "catch" apply to function calls,
and I'll work on fixing that before the next release. We have a
natural substitute in various matrix functions that return a null
matrix on failure rather than flagging an error.
>> In this case, admittedly, there's not much justification
>> function status -- other than a feeling of mine (anyone else?)
>> that it's better to keep the command namespace of manageable size.
>> I'm always somewhat reluctant to add a new command, but don't feel
>> quite the same constraint with functions.
> 100% agree.
Yes I think that's wise. However, I'm not sure I understand exactly in
some cases why something is a command rather than a function then:
It's gone in CVS, replaced by a packaged function.
* pvalue (although I see the analogy to the menu entry)
* (some of the transformation commands, although I see the case for
* modprint (requires matrix stuff, so arguably is advanced anyway)
* sprintf (recent and advanced, and has natural return value)
Some of these, I think, are simply "legacy". There's no real need
to have sprintf, for example, in both command and function form:
it's just that the command came first. Depending on how concerned
we are with backward compatibility we could get rid of some of