Re: [Gretl-devel] members of lists returned from functions
Am 11.02.2008 22:12, Riccardo (Jack) Lucchetti schrieb:
On Mon, 11 Feb 2008, Allin Cottrell wrote:
> For now I have it that list-returning user functions just
> overwrite, but perhaps we need to discuss this some more.
I'm personally in favour of the overwrite policy. The logs command
generates variables with the prefix "l_" plus the original name. This is
consistent, logical and predictable. Imagine this scenario: you have a
huge dataset with hundreds of variables, you take logs _en masse_ via
the nice and convenient "logs" command, only to find, dozens of lines
later, that what you thought was under the name "l_varname34" doesn't
contain what you want, because it's under "l_varname34a". Very
irritating, and hellish to debug. The only good thing that may come out
of this situation is the invention, if you're creative, of swearwords
previously unknown to man.
Yeah I see your point, but what about the swearwords of those who lose
their existing variable that was hand-typed with 15 million
observations? (Slight exaggeration to make my point...)
I have thought about it a little bit but could only think of a solution
for the builtin functions like the ones you're talking about: names
starting with 'l_' and the like could be made "semi-reserved" in the
manual, explaining that you risk losing them.
But IMHO the situation is totally different for user-defined functions:
users should not be required to do a risk analysis or thoroughly study
the documentation of a function before playing around with it.
Otherwise, gretl's new and great function package approach would be
unsafe by design and it would ultimately be doomed IMHO. I see no
solution for this problem except to disable the mentioned "namespace
breach". (Think of how likely it is to have series named 'y' or 'u'
or
'x' and a function author choosing those names as well. It seems to me
that the clashes I'm talking about are not just theoretical
possibilities.)
One issue is very important IMHO: dataloss by design should be
unacceptable for gretl, no matter how convenient it would be for savvy
users (or developers)!
thanks,
sven