>>>>> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> I wasn't just talking about the threaded case though - the point
TH> which I was making was that of what happens if a single threaded
TH> program alters a hash in the middle of iterating it.
TH> Currently keys and values are flattened when they are seen so any
TH> change to the hash is not reflected in the resulting list. If we
TH> are iterating instead of flattening then we need to address that
TH> somehow.
I'd rather not have the expansion performed. Some other mechanism, either
under the covers or perhaps even specified in the language.
The only real issue is if the change effects the iterator order. Changes
to values should be allowed without out any adverse effects.
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.
I'm partial to the don't do that approach. It can easily be handled
at the user level.
delete @hash{@delete_these};
@hash{keys %add_these} = values %add_these;
<chaim>
(Hmm, push(%hash, %add_these))
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
