Re: [Gretl-devel] Surprising behavior of packages editor
On Fri, 7 Jul 2017, Marcin Błażejowski wrote:
this is something I discovered durning my recent work and what can
happen in very(?) rare cases.
Situation:
1. We have two packages (FOO1.gfn and FOO2.gfn), both with public
function 'FOO_func1' (but behavior I'm describing here affects private
functions too).
2. We open in packages editor package FOO2.
3. In regular script window we run following code:
<hansl>
include FOO1.gfn
eval FOO_func1()
</hansl>
4. We open in packages editor function FOO_func1 from the FOO2 package
and... this is FOO_func1 from _FOO1_!!!
Well, 'FOO_func1', being public, can only have one definition, and
loading FOO1.gfn has overwritten the definition given by FOO2.gfn.
The long-standing behavior of gretl has been that a new function
definition overrides any previous definition (except for private
functions in packages). And in fact in this case, when gretl spotted
the conflict between public packaged functions, it removed the entire
package FOO2 from memory. (You might see on stderr, "unloading
conflicting package <name>".)
In some circumstances that _might_ be OK, but in the context you
describe it's obviously not alright: the editor window for package
FOO2 has become "orphaned" and is in a mixed-up state.
I think the best solution to this is to protect a loaded package from
having any of its public functions redefined "externally" (either by
loading another package or by defining an unpackaged function with
conflicting name). That's now in git. If you try the above again you
should find that the loading of FOO1 is rejected:
"The function FOO_func1 is already defined by package 'FOO2'"
However, I'm not finished with checking the consequences of this
change; I'll do some testing and check for fall-out.
Allin