From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13726 invoked from network); 15 Dec 1999 10:29:06 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Dec 1999 10:29:06 -0000 Received: (qmail 27688 invoked by alias); 15 Dec 1999 10:28:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9055 Received: (qmail 27681 invoked from network); 15 Dec 1999 10:28:55 -0000 Subject: Re: Namespaces again (was: RE: PATCH: Add jobdirs association to parameter module) In-Reply-To: from Peter Stephenson at "Dec 14, 1999 11:46:41 pm" To: pws@pwstephenson.fsnet.co.uk (Peter Stephenson) Date: Wed, 15 Dec 1999 10:28:52 +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 think Andrej was saying ${a.b} should be invalid, which I agree with >since otherwise it complicates things mightily --- i.e, if there are any >dots in a name, there must be one at the beginning. Just allowing >`.' separators might be enough for testing, but it's too much of a hack for >normal use. Unfortunately, catching all the relevant entry points to the >parameter code to test this sort of thing tends to be rather a nuisance. I don't see a problem with allowing ${a.b}. In fact, I see it being useful in scripts, and it doesn't complicate anything. The shell's special parameters (other than those with historically established names) should all have names beginning with ".", but names not beginning with "." that contain "." should be available to the user. >It would be nice to get the full module name into the namespace, but >perhaps ${.parameter.options} is a bit long. No need. Put the parameters from the zsh/* module namespace into the ${.zsh.*} parameter namespace; we can manage the clashes as we already do. Other module writers can do the same kind of namespace tricks. We could formalise that: parameters whose names begin with "." have a hierarchical namespace managed in the same way as the module namespace and with the same top-level delegations. That would give every potential module writer some guaranteed parameter namespace. Next possibility: add parameters ${.zsh.path}, ${.zsh.module_path}, etc., as aliases for $path, $module_path and so on. Then we can have an option to make the non-. names non-special. Only zsh-specific scripts could do that, of course, but the freeing of the namespace is a non-trivial advantage that would make it desirable. > mapfile is perhaps the >only candidate, but then ${.mapfile.what?}, or can we get away with >${.mapfile} ? If following the module namespace, make it ${.zsh.mapfile}. If we want to add other parameters to that module later, there's nothing to stop ${.zsh.mapfile.foo} coexisting. -zefram