From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25401 invoked from network); 10 Sep 2000 21:35:04 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Sep 2000 21:35:04 -0000 Received: (qmail 29341 invoked by alias); 10 Sep 2000 21:34:32 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12789 Received: (qmail 29333 invoked from network); 10 Sep 2000 21:34:31 -0000 Subject: Re: Module hierarchies, aliasing, and dependencies In-Reply-To: from Peter Stephenson at "Sep 10, 2000 10:16:14 pm" To: Peter Stephenson Date: Sun, 10 Sep 2000 22:35:00 +0100 (BST) CC: zsh-workers@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Peter Stephenson wrote: >"Bart Schaefer" wrote: >> Wouldn't it be better to rely on a symbol that's defined *inside* the >> module to determine whether a module has been loaded? Similar to the way >> (provides 'name) works in emacs libraries? > >Yes, this sounds better. That would have fixed [some of] Will's >difficulties. Also, I've been wondering for a while how to provide a test >version of a module under a different name. This would be a good solution. There's an issue here, that a module that calls functions from another module can't be loaded at the dlopen() level (depending on system). The module dependency system is there to handle this, but it will have problems with the kind of scheme you describe. For example, 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). 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). We're stuck with this external naming in many respects, at least until we start putting dependency-type information in the module files themselves, in a form that can be read without doing a dlopen(). This is something I've considered before, but not implemented because of concerns about what various dynamic linkers might accept. But if we could do it, we could include in this metadata the name of the module's boot function, making it possible to load a module under any name on any system. If we can relax the connection between modules' internal names and disk names in this way, it would then be feasible to introduce a distinction between the module file and the logical modules in contains. We already have a special-case relaxation of the one-to-one correspondence -- modules linked in to the main executable -- and I can see advantages in fully generalising it. -zefram