Re: [Gretl-devel] built-in functions and namespace issues
Am 24.11.18 um 20:56 schrieb Allin Cottrell:
On Sat, 24 Nov 2018, Sven Schreiber wrote:
> I, too, think that it's OK. In principle we could offer some kind of
> promise which name pattern will never be used for a built-in function
> and thus will be safe forever, but it's probably overkill.
As I mentioned in response to Marcin, I believe we can offer such a
promise: built-in functions will not have an underscore in their names.
OK.
> I don't really see the need for the exception for private
functions.
> Since gretl doesn't have overloading of functions and such, couldn't
> the rule simply be "you mustn't use names of built-in functions,
> period"? It seems to me that this isn't too much to ask for package
> authors.
"You mustn't use names of built-in functions, period" is fine
contemporaneously (if that's a word).
But I'm thinking of the case where a package writer has defined a
private function "foo" and then at some later date "foo" is added as
a
built-in. This is unlikely to happen often (and it should never happen
if Marcin's rule is followed), but if it does happen I think it's
reasonable that the existing private function is still accepted (with
a warning).
This is a privileged treatment of private functions in packages, and
it's very nice of you. However, I don't see the fundamental difference
to a non-packaged function that somebody uses locally, where we agree
that people will be required to change those names if a new built-in
comes along. So I advocate the following:
- Built-in functions are taboo, period.
- Before releasing a new gretl version, or even before adding the new
built-in to git, we screen all function packages for a clash. If there
is one, we either require the package author(s) to change the respective
private function name, or perhaps in certain circumstances we change the
new built-in's name.
But I'm also fine with the current solution, but in a sense it's
probably more error-prone on gretl's side.
cheers,
sven