Re: [Gretl-devel] Two GUI entry points for a package
Am 05.12.2018 um 15:56 schrieb Sven Schreiber:
Am 05.12.2018 um 15:54 schrieb Allin Cottrell:
> On Wed, 5 Dec 2018, Sven Schreiber wrote:
>
>>
>> One step further in this experiment: It seems that when A depends on
>> B, the private functions of package B are still _not_ available in
>> package A. (Right?) This is not too surprising, but in my case
>> creates a problem.
>
> Right. I guess we could introduce a third category for packaged
> functions: public, private and shared-with-pals. But I haven't yet
> made any attempt to think through the implications of that. Or maybe
> better, keep the public/private dichotomy but add a "hidden" flag that
> would mean, don't expose this public function at user level.
>
No need to rush anything here.
Hi, when I wrote the other message on the users list about the SVECM GUI
right now I had another idea:
What if something like a "deep dependence" between packages is
introduced as a possibility, and implemented via a temporary copy? So if
a package A deep-depends on B, then gretl wouldn't just do an "include
B.gfn" like a user would do, but it would copy over all the functions
from B on-the-fly and save to disk a temporary version of A augmented
with everything there is in B. This would imply code duplication, but
only for the time of the running gretl session. Whenever B is updated,
those changes carry over to A as soon as a new "include A.gfn" is executed.
The advantage would be that all the private functions in B would become
private functions in A and thus would be accessible in A, without having
to introduce a new function category like "shared" or whatever.
In pseudocode form:
1) include A.gfn # User's command, and gretl finds that A deep-depends
on B as per its spec
2) <gretl prepares a temporary package A__B.gfn (which must be deleted
at the end of the session)>
3) <gretl copies all public and private functions from A and B into
A__B, makes sure there are no duplicate names (else it's A's fault) and
saves A__B.gfn to a suitable temp dir>
4) include A__B.gfn # gretl automatically executes this
5) <gretl executes the rest of the user code>
One complication might be if the user for some reason does both include
A.gfn and include B.gfn and how to deal with the name duplication of the
public functions then. Hm.
FWIW,
sven