In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> I'd rather not have the expansion performed. Some other mechanism, either
> under the covers or perhaps even specified in the language.
Absolutely. Both mechanisms have been suggested - my under the
covers proposal in RFC 136 and the language proposal in the form
of the lazy keyword in some other RFC whose number I forget.
> The only real issue is if the change effects the iterator order. Changes
> to values should be allowed without out any adverse effects.
Well if we allow value changes in the middle of iterating either
keys or values then that is a user visible behaviour change which
potentially needs to be hideable in p52p6 translation.
> Changes to the iterator order (inserted/deleted keys, push/pop) can
> be either, "don't do that", or queued up until the iterator is done or
> past the effected point.
Queueing up internally is likely to be complicated and expensive
for relatively little gain.
Allowing changes can I believe be made safe from the point of view
that it won't segv. It just may cause things like seeing a key twice
or not seeing some at all.
There's the still the question of preserving old semantics when
translating old scripts though.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
