From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29129 invoked from network); 14 Dec 1999 23:45:48 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Dec 1999 23:45:48 -0000 Received: (qmail 27830 invoked by alias); 14 Dec 1999 23:45:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9051 Received: (qmail 27823 invoked from network); 14 Dec 1999 23:45:43 -0000 To: zsh-workers@sunsite.auc.dk Subject: Re: Namespaces again (was: RE: PATCH: Add jobdirs association to parameter module) In-reply-to: "Sven Wischnowsky"'s message of "Tue, 14 Dec 1999 15:30:01 +0100." <199912141430.PAA03968@beta.informatik.hu-berlin.de> Date: Tue, 14 Dec 1999 23:46:41 +0000 From: Peter Stephenson Message-Id: Sven Wischnowsky wrote: > - What exactly would we gain by using different tables? It's really an internal matter. If you can give the same impression easily without that's probably OK. > - In which way would they remain `invalid'? Especially from a user's > point of view -- who should still be able to say `.a.b=c'. 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. It would be nice to get the full module name into the namespace, but perhaps ${.parameter.options} is a bit long. I think it's still early enough days with the parameter module to make this change without too many people throwing themselves off millennial landmarks. We should decide if others need it. mapfile is perhaps the only candidate, but then ${.mapfile.what?}, or can we get away with ${.mapfile} ? -- Peter Stephenson