Re: [Gretl-devel] Two GUI entry points for a package
On Tue, 15 Jan 2019, Sven Schreiber wrote:
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>
Interesting. But I think what you're describing could be done just in
memory, without writing a temporary package file. The idea would be:
1) Load A.gfn as usual, detect deep-dependency on B.
2) Load B.gfn in a (new) "merge mode", whereby its public functions
and added to A's public list and its private functions to A's private
list. So package B is not really loaded as such, its content is just
merged into that of A on the fly.
A.gfn and B.gfn on disk would not be affected.
Allin