From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24832 invoked from network); 14 Dec 1999 14:30:08 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Dec 1999 14:30:08 -0000 Received: (qmail 22680 invoked by alias); 14 Dec 1999 14:30:03 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9045 Received: (qmail 22671 invoked from network); 14 Dec 1999 14:30:02 -0000 Date: Tue, 14 Dec 1999 15:30:01 +0100 (MET) Message-Id: <199912141430.PAA03968@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Tue, 14 Dec 1999 17:18:01 +0300 Subject: Re: Namespaces again (was: RE: PATCH: Add jobdirs association to parameter module) Andrej Borsenkow wrote: > > Well, if someone wants to see if he can find any problems with this, > > it would be the patch below... > > > Is this really all that is needed? If I understand it correctly, this patch > simply makes `.' valid character for parameter names. It means, that both foo > and .bar.foo are put in the same (and the only) table ... both are happily > listed with `set' ... As I said: it's the simplest `solution' I saw -- and I really wanted it only to play with it to see if there are places where parameter names with dots in it (on the user side, independent of how they are actually implemented) cause problems. > what's worse, it makes `foo.bar' hihgly ambiguous. It may > break scripts that do not expect `.' in parameter names ... In which way ambiguous? > I'd expect `.' be treated as names separator - and only in context `.foo.bar'. > Thus `foo.bar' as identifier remains invalid alltogether (eliminating $foo.bar > ambiguity). We'll have default namespace for all names without dot and explicit > namespaces for name starting with dot. All commands should behave just as normal > Unix :-) - everything starting with dot is "hidden" by default. This should have > the minimum impact (as long, as users do not request namespaces, they simply do > not see them at all). Many questions come to mind, some of them: - What exactly would we gain by using different tables? - 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'. - Are you suggesting new options or new ways of argument handling for builtins like set to select a `namespace'? It would be easy to `hide' parameter names starting with a dot by just making set/typeset not print them -- unless a certain (new) option is given. And something similar could be used to make it list only parameters starting with `.something' which would give us what I asked above. And that without actually using multiple tables, because I /think/ that wouldn't be nicely small and easy to implement -- and I still don't see a real advantage of that anyway. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de