In message [EMAIL PROTECTED]
Chaim Frenkel [EMAIL PROTECTED] wrote:
"TH" == Tom Hughes [EMAIL PROTECTED] writes:
TH Well if we allow value changes in the middle of iterating either
TH keys or values then that is a user visible behaviour change which
TH potentially needs to be
"TH" == Tom Hughes [EMAIL PROTECTED] writes:
The only real issue is if the change effects the iterator order. Changes
to values should be allowed without out any adverse effects.
TH Well if we allow value changes in the middle of iterating either
TH keys or values then that is a user visible
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
We punt. If the programmer wants consistent data in a multithreaded
program, he or she needs to lock the hash down. I'm all up for the
iterators looking at the hash as it exists--if the programmer wants
a snapshot of
At 05:17 PM 9/5/00 -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
This could be a lot more efficient than modifying the vtbl and filling
up the stack with the keys. I really am suspicious of replacing the
vtbl entry, there may be more than one thread working
"TH" == Tom Hughes [EMAIL PROTECTED] writes:
TH I guess we can translate all uses of keys and values when doing
TH the p52p6 conversion - so that this:
TH foreach my $x (keys %y)
TH {
TH $y{$x+1} = 1;
TH }
TH becomes:
TH foreach my $x (@temp = keys %y)
TH {
TH $y{$x+1} = 1;
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
Or have a "next" vtable function that takes a token and returns the next
entry in the variable. Each iterator keeps its own "current token" and the
variable's just responsible for figuring out what should get
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Implementation of hash iterators
=head1 VERSION
Maintainer: Tom Hughes [EMAIL PROTECTED]
Date: 20 Aug 2000
Last Modified: 4 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 136
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL =head2 Freezing state for keys and values efficiently
PRL I believe this problem can be solved by using the vtable for the
PRL hash to wrap any mutating functions with a completion routine that
PRL will advance the iterator to
