From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25850 invoked from network); 10 Sep 2000 22:30:54 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Sep 2000 22:30:54 -0000 Received: (qmail 3627 invoked by alias); 10 Sep 2000 22:30:14 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12790 Received: (qmail 3620 invoked from network); 10 Sep 2000 22:30:13 -0000 From: "Bart Schaefer" Message-Id: <1000910222957.ZM4723@candle.brasslantern.com> Date: Sun, 10 Sep 2000 22:29:57 +0000 In-Reply-To: Comments: In reply to Zefram "Re: Module hierarchies, aliasing, and dependencies" (Sep 10, 10:35pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: Module hierarchies, aliasing, and dependencies MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 10, 10:35pm, Zefram wrote: } Subject: Re: Module hierarchies, aliasing, and dependencies } } [E.g.] zsh/deltochar depends on zsh/zle: with dependencies set up right, } zsh/zle will be loaded automatically before zsh/deltochar. But if you } load zsh/deltochar under the name "local/deltochar" (or just "deltochar", } or anything else) zsh/zle won't be loaded first, and so the load will fail } (unless zsh/zle was already loaded). I don't think this is really a problem -- the issue is not automatically discovering that local/deltochar depends on zsh/zle, it's discovering that local/zle has already substituted for zsh/zle when loading zsh/deltochar. Put another way, I'm quite happy to have to explicitly state dependency of local/deltochar on zsh/zle, external to any module. However, if the user explicitly loads local/zle, I want zsh to discover that it does not also need to load zsh/zle at the time zsh/deltochar is loaded. An alternate solution has just occurred to me ... in the setup function in local/zle, one could simply scan the module list for any module that has a dependency on zsh/zle, and substitute the name local/zle in its place. However, that would not help if `zmodload -d ... zsh/zle' was used after the local/zle setup function was called, so some additional magic would also be needed. } There's another issue that on some systems name clashes between symbols } exported by different modules isn't permitted, so every module's boot } function has to be named differently, so we need to know the module's } internal name in order to call any code in it. Loading under a different } name just won't work on that kind of system (as I mentioned upthread). Under what circumstances would it be necessary to call any code without knowing the actual name of the shared object? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net