From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25776 invoked from network); 21 Dec 1999 10:54:49 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 21 Dec 1999 10:54:49 -0000 Received: (qmail 21254 invoked by alias); 21 Dec 1999 10:54:41 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9127 Received: (qmail 21247 invoked from network); 21 Dec 1999 10:54:40 -0000 Subject: Re: PATCH: alias modules In-Reply-To: from Peter Stephenson at "Dec 20, 1999 10:23:14 pm" To: Peter Stephenson Date: Tue, 21 Dec 1999 10:54:31 +0000 (GMT) CC: zsh-workers@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL65 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Peter Stephenson wrote: >any reason you haven't done this the way I suggested, which would have put >aliasing under user control, We don't want aliasing under user control. My view is that aliases are for backward compatibility only. The point of hierarchical module names is that each module can have a canonical global name, and users loading modules can specify unambiguously which module they want. To do that, the user has to give the fully-qualified module name at some point. And since modules are usually (auto)loaded in initialisation files anyway, there's no typing saved by letting the user set up an abbreviated name. But really the reason why I did it this way is that it seems neater. It's adding no new semantics, just using the existing infrastructure (module dependencies). zsh has far too much semi-hidden state as it is; it's time we started using its existing capabilities to their full potential, rather than doing each new thing in C. The new completion system is heading that way, much to my delight. > would have allowed zmodload to show up aliases >clearly zmodload -d OK, this makes no distinction between alias modules and other dependencies. But OTOH, I don't think we want to treat straight aliases specially. What if we split a module into several: with this system, we can make the old name an empty module depending on all the new modules, and it is treated exactly like the 1-to-1 aliases. > and wouldn't have filled the place up >with bogus modules (some 30k each here)? Oh. They're 3620 bytes each here, and I assumed they'd be small everywhere, since they contain almost no code. But as I explained earlier, my intention is that there won't eventually be so many. 3.1.7 should contain aliases only for those modules that existed in 3.1.6, and we should consider at some point which modules are really important enough to warrant backward compatibility with the old names. -zefram