Thanks. I had actually read that sentence but had 'misunderstood' it - thinking of it only in the foreach loop context and not realizing the same thing applies in a non-loop. By the way, your analogy was really helpful.

If I am now understanding the sentence correctly, I can do something like the following:

Presumably this would 'eat' the 'undef' token and make the lazy-a** conductor go back to the front of the bus and start collecting tickets again :)

One more follow-up

If I only remove elements from the cache using 'each' followed by 'delete' and if I do a delete before each add, it would seem that your analogy if taken literally would give a nice (for my purposes) circular array type behavior. I.e., once I have filled the cache, so that adds follow deletes, then each new add fills the seat left by the previous delete and the conductor won't get around to the new add until he goes around again.

Does this indeed describe the behavior?

Note: for my purposes this would be wonderful - combining the benefits of a circular array with that of a hash. Specifically, then 'each' would return the oldest entry (and hence likely most stale cache entry) for deletion, while the hash allows for random access of elements.

To the question in your previous post I would say that should work. Nice line by the way. UPDATE: Seems it won't work after all, see johngg's experiment

But the delete bevor add idea won't work, because hashed items get stored into specific slots depending on their hash value. I.e. new passengers always want to go to a seat that depends on their social security number, not to the seat that was vacated last.

What happens when a passengers wants a seat that is occupied, There are two mayor strategies to handle this (that I remember), one is to let more than one passenger sit on a seat, the other is to calculate another seat in a deterministic pattern until the passenger finds a free one (for example the next seat, or the 13th seat from this one). I believe perl hashes use the first method (more than one on a seat) but I'm not sure.

To the question in your previous post I would say that should work.

So would I and the line does look rather nice. Unfortunately, it doesn't seem to work as you might expect. It does look as if it is resetting the iterator but it is failing to consistently retrieve the values from the hash, only managing to get the value for key "six" twice and not getting any others.

knoppix@Microknoppix:~$ perl -Mstrict -wE '
> my %hash = (
>    one => q{ein},
>    two => q{zwei},
>    six => q{sechs},
>    );
> say qq{@{ [ %hash ] }};
> for ( 1 .. 9 )
> {
>     my ( $k, $v ) = each %hash || each %hash;
>     say qq{$_: $k => $v}
> }'
six sechs one ein two zwei
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
1: six => 
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
2: one => 
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
3: two => 
4: six => sechs
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
5: one => 
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
6: two => 
7: six => sechs
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
8: one => 
Use of uninitialized value $v in concatenation (.) or string at -e lin
+e 11.
9: two => 
knoppix@Microknoppix:~$
[download]

I can't puzzle out what is going on here. I wondered if it was a precedence problem but changing each %hash to each( %hash ) made no difference.

Can anyone shed any light on what's happening here?

Update: A different approach to prove to myself that the each would behave as described.

knoppix@Microknoppix:~$ perl -Mstrict -wE '
> my %hash = (
>    one => q{ein},
>    two => q{zwei},
>    six => q{sechs},
>    );
> say qq{@{ [ %hash ] }};
> my $ct;
> for ( 1 .. 3 )
> {
>     while ( my ( $k, $v ) = each %hash )
>     {
>         $ct ++;
>         say qq{$ct: $k => $v}
>     }
> }'
six sechs one ein two zwei
1: six => sechs
2: one => ein
3: two => zwei
4: six => sechs
5: one => ein
6: two => zwei
7: six => sechs
8: one => ein
9: two => zwei
knoppix@Microknoppix:~$
[download]

Cheers,

JohnGG

I was interested so I performed a bit of an experiment. If I understand correctly, this is similar to the setup you are aiming for:

#!/usr/bin/perl
use strict; use warnings; use 5.010;

my @az = 'a'..'z';
my %cache = ( a => 1, b => 1, c => 1 );

for (1..20) {
  my $key = each %cache || ( say "back to front!" and each %cache );
  say $key;
  delete $cache{$key};
  $key = $az[rand @az] . $key;
  $cache{$key} = 1;
}
[download]

Sample Result:

c
a
b
sa
qsa
zc
back to front!
zqsa
zzc
wb
izzc
ezqsa
cizzc
nwb
nnwb
eezqsa
back to front!
icizzc
bnnwb
neezqsa
back to front!
sneezqsa
jicizzc
[download]

So, you don't get perfect "oldest first" behavior. In particular, it is fully possible that you evict the most recently cached item. In the bus analogy, if any new cache items sit in a seat behind where the conductor is, they may be evicted prematurely. However, some amount of "oldest first" does seem to exist and from what you've said, this is probably "good enough" for your needs.

I do wonder whether adding items might eventually/occasionally cause perl to recompute the hash which might reset the conductor or cause an "old" key to be moved to a seat in front of the conductor's location so that the old key gets missed in a pass.

Good Day,
    Dean