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 Message-ID: <19990202200736.B4792@fysh.org> Date: Tue, 2 Feb 1999 20:07:36 +0000 From: Phil Pennock To: zsh-workers@sunsite.auc.dk Subject: Re: Associative array ordering and selective unset (Re: Example function) Mail-Followup-To: zsh-workers@sunsite.auc.dk References: <199902011048.LAA07559@beta.informatik.hu-berlin.de> <990201090246.ZM31742@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 In-Reply-To: <990201090246.ZM31742@candle.brasslantern.com>; from "Bart Schaefer" on Mon 1 Feb 1999 (9:02 -0800) Organisation: Organisation? Here? No, over there ----> X-Disclaimer: Any views expressed in this message, where not explicitly attributed otherwise, are mine and mine alone. Such views do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. X-Mailing-List: 5188 Typing away merrily, Bart Schaefer produced the immortal words: > On Feb 1, 11:48am, Sven Wischnowsky wrote: > } 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. > > 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. A pointer in each to embed a linked list? -- --> Phil Pennock ; GAT d- s+:+ a23 C++(++++) UL++++/I+++/S+++/B++/H+$ P++@$ L+++ E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+ G+ e+ h* r y?