From mboxrd@z Thu Jan 1 00:00:00 1970 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes Sender: B.Stephens@isode.com To: zsh-workers@sunsite.auc.dk Subject: Re: Associative array ordering and selective unset (Re: Example function) References: <199902011048.LAA07559@beta.informatik.hu-berlin.de> <990201090246.ZM31742@candle.brasslantern.com> MIME-Version: 1.0 From: Bruce Stephens Date: 01 Feb 1999 17:39:12 +0000 In-Reply-To: "Bart Schaefer"'s message of "Mon, 1 Feb 1999 09:02:46 -0800" Message-ID: User-Agent: Gnus/5.070069 (Pterodactyl Gnus v0.69) XEmacs/20.4 (Emerald) X-Mailing-List: 5155 "Bart Schaefer" writes: > On Feb 1, 11:48am, Sven Wischnowsky wrote: > } Subject: Re: Example function > } > } I was thinking about this... we could make the code keep a counter in > } assoc arrays, increment it whenever a new key is added and store the > } current value in the structure for this new element. Then we can treat > } the whole thing as being sorted by `time of addition'. > } > } Hm, does this sound like the right thing? > > Almost. Something about it doesn't seem quite right to me, but I > can't put my finger on what different behavior I'd expect. It would be a bit tricky to reorder the associative array, wouldn't it? i.e., if I set up some configuration, and then want to insert some pattern before some others, then I'd need to recreate the associative array. Maybe that's OK, but it feels a bit awkward. Emacs (and other Lisps) has assoc-lists, which is maybe a better model for this: they're explicitly lists (so they have ordering), but you can access them by key. I've no idea how this would map onto a shell, but perhaps this is saying that associative arrays don't quite fit what's wanted. > I don't like the idea that every parameter table hash would end up > with another integer of overhead in every entry, but maybe that's > not so bad. I agree, the extra integer is probably trivial.