From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19942 invoked from network); 15 Dec 1999 20:30:55 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Dec 1999 20:30:55 -0000 Received: (qmail 5205 invoked by alias); 15 Dec 1999 20:30:49 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9069 Received: (qmail 5196 invoked from network); 15 Dec 1999 20:30:47 -0000 To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: PATCH: hierarchical module names In-reply-to: "Zefram"'s message of "Wed, 15 Dec 1999 10:52:15 GMT." Date: Wed, 15 Dec 1999 20:31:47 +0000 From: Peter Stephenson Message-Id: Zefram wrote: > 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. Perhaps we don't even need the aliased modules (though I don't quite know how you'd plan to implement this anyway). zmodload could have a builtin aliasing feature that says that zle is really zsh/zle; the relevant aliases are set up. (This is at a low enough level that `zmodload -e zle' etc. work too, of course.) If you could do the same thing with zmodload, it would be a neat way of tricking zmodload for testing etc. --- e.g. you unalias foo from standardmods/foo and alias it to testingmods/foo, then anything which uses module foo still works with the other module, no fpath trickery. This is how Stroustrup envisaged namespaces in C++ working, so we'd be in quite good company. I'll hold off sticking the patch into the development versions until some sort of backward compatibility has emerged. -- Peter Stephenson