Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Associative arrays, structured namespaces
- X-seq: zsh-workers 4088
- From: Bruce Stephens <b.stephens@xxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx
- Subject: Re: Associative arrays, structured namespaces
- Date: 10 Jun 1998 13:07:29 +0100
- In-reply-to: Zefram's message of "Wed, 10 Jun 1998 11:44:51 +0100 (BST)"
- References: <199806101044.LAA12918@xxxxxxxxxxxxxxxx>
- Sender: B.Stephens@xxxxxxxxx
Zefram <zefram@xxxxxxxxx> writes:
> Bruce Stephens wrote:
> >This strikes me as an excellent idea. Presumably the implementation
> >is similar to that of associative arrays, though?
>
> No. The way it's done in Elate, the shell just treats the structured
> variable name as an opaque string. It's only convention that interprets
> the name as having structure. Associative arrays is a completely
> separate issue.
Yes, I wasn't thinking clearly. I was thinking that adding a SET
function to shell.path (which would be called shell.SET, I suppose)
and all that kind of functionality would be harder without regarding
things as separate associated arrays, but I'm clearly wrong: it's
still dead easy with a single namespace, because you know exactly what
you're looking for.
Supposing zsh has a hash table of parameter names which pointed at
values; couldn't the hash just be replaced by a btree or something?
Wouldn't that provide enough to reasonably efficiently produce all
variables beginning with some prefix?
Probably you're right, though: associative arrays ought to be done
specially, if they're done at all. Come to think of it, having an
associative array very_long_prefix.put_keys_next.* would probably be
too expensive done as a set of variables. Yeah, you're definitely
right: keep things simple.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author