http://qs321.pair.com?node_id=285402


in reply to array confusion

As has already been explained for (LIST) aliases the iterator variable to the apropriate member of the list, just as @_ is actually a list of aliases to the passed parameters. (map{} and grep{} do the same thing as for incidentally, while/until does not.)

This is easily overlooked and can result in strange things happening by oversight. For instace replace @look_for with qw(look for) and you'll get an error. Same if you replace it with (1,2,3). (The workaround is to write for (my @temp=qw(...)). You might think these examples are obvious but they can be less so when the action is at a distance when combined with the behaviour of @_:

sub one { two(@_); } sub two { s/(.)\1/$1/ for @_ } one(qw(aa bb cc))

One interesting and subtly obvious (once you think about it) example of where this doesn't appear to happen is when iterating over the keys of hash. In this case the iterator is not aliased to the actual key but to a copy of the key.(otherwise very odd things could happen to the hash, furthermore the keys of a hash dont live in SV's so need to be placed in one before they can be accessed in Perl land)

If you really want @look_for to contain aliases to $name, $nerd etc, then you can do two things, use a reference to @_ to create an array ref of aliases, or use the module Array::RefElem

sub alias_array { \@_ } my $look_for = alias_array($name,$nerd,$noodle,$froodle,); foreach my $item (@$look_for) { $item =~ s/$i_seek/ /g; }

---
demerphq

<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...