Re^2: Opinions on adding functionality to Tie::Hash::Sorted

gaal,
They would be direction switches. The reason for naming them explicitly would be so code that used them would be clear in what was going on but you are right - functionally only one is needed.

A prev and next method were supposed to be coupled with the peek methods (which would actually change the iterator), but I got trigger happy and posted before the brain dump was complete. Thanks for mopping up the grey matter.

Cheers - L~R

Comment on Re^2: Opinions on adding functionality to Tie::Hash::Sorted

Replies are listed 'Best First'.
Re^3: Opinions on adding functionality to Tie::Hash::Sorted by gaal (Parson) on Jul 18, 2004 at 15:12 UTC
Hmmm, I just thought of another method that might be useful: rewind, to reset the iterator. But that's probably low priority, seeing as there's no natural way to express that for unordered hashes in Perl.	[reply]
Re^4: Opinions on adding functionality to Tie::Hash::Sorted by Limbic~Region (Chancellor) on Jul 18, 2004 at 15:24 UTC
gaal, seeing as there's no natural way to express that for unordered hashes in Perl. The iterator is reset anytime there is a new call to keys, or values. each will only do this once it reaches the end of the hash. This can cause very unexpected behavior if you mix and match - see the following: `#!/usr/bin/perl use strict; use warnings; my %hash = (one=>1, two=>2, three=>3, four=>4, five=>5); my $flag; # prevent infinite loop while ( my ($key, $val) = each %hash ) { if ( $val == 4 && ! $flag ) { my @keys = keys %hash; print "\t$_\n" for @keys; $flag = 1; } print "$key : $val\n"; }` [download] There very well may be some good in saving off the iterator, resetting it, and restoring it so this doesn't go bonkers as it does with real hashes. I will have to give some thought to this though. Cheers - L~R Modified wording with regards to resetting iterator as pointed out by davido.	[reply] [d/l]
Re^5: Opinions on adding functionality to Tie::Hash::Sorted by gaal (Parson) on Jul 18, 2004 at 15:35 UTC
Yikes! I wasn't aware of that; for some reason I'd been assuming each `each` keeps its own state, somewhat like `..`s do. Thanks for the heads up!	[reply] [d/l] [select]