From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13873 invoked from network); 15 Dec 1999 10:52:25 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Dec 1999 10:52:25 -0000 Received: (qmail 5139 invoked by alias); 15 Dec 1999 10:52:18 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9056 Received: (qmail 5132 invoked from network); 15 Dec 1999 10:52:17 -0000 Subject: Re: PATCH: hierarchical module names In-Reply-To: from Peter Stephenson at "Dec 14, 1999 11:45:32 pm" To: pws@pwstephenson.fsnet.co.uk (Peter Stephenson) Date: Wed, 15 Dec 1999 10:52:15 +0000 (GMT) Cc: zsh-workers@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL48 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Peter Stephenson wrote: >I don't like this bit. It means zmodload behaves differently from the way >it's done for several years now. I don't see why the main modules >shouldn't keep their old names. Ah, yes, there's another thing that got lost as the patch grew. I'd intended to do some sort of backward compatibility, but hadn't decided quite how to do it. I think the old modules do need to keep their historical names, one way or another. But I don't see a problem with all new modules getting a prefix. "zsh/", in particular, is not an onerous amount of extra typing. >Or, if you prefer, you can make a name without a slash equivalent to the >same with zsh/ stuck in front. That might be the simplest. This is a reasonable solution. Three other solutions occur to me: 1. Have only the historically-established names be aliased. 2. Alias the historically-established names by filesystem links, so that the executable doesn't need to know about specific names. 3. Have alias modules for the historically-established names. We'd have, for example, a `zle' module, which has a built-in dependency on `zsh/zle' but doesn't actually do anything itself. So loading `zle' would have the effect of loading `zsh/zle', and zmodload would then report both `zle' and `zsh/zle' as loaded. I favour solution 3. It seems to maintain the greatest degree of compatibility, while not requiring any changes to the mechanism. >> * There is no way to load a module from a specified filename. There >> should probably be a distinct option for this, if the capability is >> to exist at all. > >I don't think this is a worry; you can write a function with some $fpath >trickery if you're desparate. That's pretty much what I thought. The only issue is what happens if the module file has the `wrong' name, or is in a subdirectory with the wrong name, for example, where it is compiled in the zsh build tree. That's what the extra option would be for. Possible technique: have zmodload check module name syntax at command-line time, rather than at load time, and then extend the syntax to allow : to specify loading a module from a specific file. -zefram