This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix iteration of nested hashes
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 18 Sep 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 255
Version: 2
Status: Developing
=head1 ABSTRACT
This RFC proposes that the internal cursor iterated by the C<each> function
be stored in the pad of the block containing the C<each>, rather than
being stored within the hash being iterated.
=head1 DESCRIPTION
Currently, nesting two C<each> iterations on the same hash leads to
unexpected behaviour, because both C<each>s advance the same internal
cursor within the hash. For example:
%desc = ( blue => "moon",
green => "egg",
red => "Baron" );
while ( my ($key1,$value1) = each %desc )
{
while ( my ($key2,$value2) = each %desc )
{
print "$value2 is not $key1\n"
unless $key1 eq $key2;
}
}
print "(finished)\n";
It is proposed that each C<each> maintain its own cursor (stored in the pad
of the block containing it) so that the above example DWIMs.
=head1 MIGRATION ISSUES
Minimal. No-one nests iterators now because it doesn't work.
Usages such as:
$x = each %hash;
$y = each %hash;
@z = each %hash;
would change their behaviour, but could be translated if p52p6 defined:
sub p5_each(\%) { each %{$_[0]} }
and globally replaced each Perl 5 C<each> by C<p5_each>.
There would not (necessarily) be any effect on the use of FIRSTKEY and NEXTKEY
in tied hashes, since the compiler could still determine which should be
called. However, tied hashes that use an internal cursor might behave
differently, if nested.
=head1 IMPLEMENTATION
Store the cursor in the pad of the block in which the C<each> is defined,
rather than within hash.
=head1 REFERENCES
RFC 136: (Implementation of hash iterators) suggests separate iterators for C<each>
and C<keys>/C<values>.
