From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24528 invoked from network); 10 Jun 1998 10:28:24 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 10 Jun 1998 10:28:24 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id GAA04351; Wed, 10 Jun 1998 06:23:40 -0400 (EDT) Resent-Date: Wed, 10 Jun 1998 06:23:40 -0400 (EDT) Sender: B.Stephens@isode.com To: zsh-workers@math.gatech.edu Subject: Associative arrays, structured namespaces References: <199806092002.VAA05396@taos.demon.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: Bruce Stephens Date: 10 Jun 1998 11:24:05 +0100 In-Reply-To: Zefram's message of "Tue, 9 Jun 1998 21:02:21 +0100 (BST)" Message-ID: X-Mailer: Gnus v5.6.10/XEmacs 19.16 - "Lille" Resent-Message-ID: <"OB5us.0.t31.hwbVr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4082 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Zefram writes: > One of the conventions I established was that all environment > variables, except for strictly user-generated ones, have structured > names. For example, the equivalent of the Unix "PATH" variable is > called "shell.path". The equivalent of "LOCALE" is called > "user.locale". This means that scripts, or the user at the shell > prompt, can use *any* alphanumeric variable name, without any risk > of colliding with anyone else's variables, now or in the future. > And utility writers have a guaranteed way to define variables > special to a particular utility without clashing with anyone else's > variables, so there's none of this "MAILFILE" nonsense. This strikes me as an excellent idea. Presumably the implementation is similar to that of associative arrays, though? If you're going to have structured namespaces, I'd like to be able to use them to do things I'd otherwise use associative arrays for, I think, so I'd like ways of asking for all variables like "shell.*" and stuff. Oh, maybe there are quoting issues I haven't thought of. Anyway, this looks quite clean. What's then needed is some way of tying these names to other names, so that PATH connects correctly to shell.path and so on. This would be a good opportunity to generalise things a bit, and allow arbitrary shell functions to be called when a variable gets set or read, and stuff like that. This is all in ksh93, isn't it? Another reason for doing it.