On Thu, 17 Jan 2019, Sven Schreiber wrote:
Am 17.01.2019 um 08:57 schrieb Riccardo (Jack) Lucchetti:
> On Tue, 15 Jan 2019, Sven Schreiber wrote:
>
>>> 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.
>>
>> If that's easy internally, it sounds quite nice, yes.
>
> I've marked the relevant GUI string for translation. I believe we
> should update the packages tex file on this, which is quite
> important.
Yes. OTOH maybe some "secret" testing period without a public
explanation of the new feature wouldn't hurt, either, so this may
not be so urgent.
Yes, I had in mind such a testing period before publicizing the
change.
> A question (no time to check myself, sorry). If A has B as a
> sibling and B has C, is C a sibling to A?
I haven't had time to make the change yet, but it now seems to me that
"sibling" is the wrong word, since siblinghood is inherently mutual
(also transitive) and I don't have that in mind here. I'm now thinking
of "host" (or perhaps "server"). If package A specifies B as
"host"
(let's say) that gives A access to B's private functions, but not vice
versa.
I haven't even thought about multiple layers of hosting, but as things
stand the answer to the question above is No.
Allin