in reply to New behavior of 'each' with respect to references

It's not just each, but keys and values as well.

If it were just hash references that were accepted, I'd say that it's not that big if a change. You're still getting some validation since it's only unblessed references that are accepted.

However, what's going to be the expected results when performed on an array reference? Don't have a 5.14 installed to test it.

  • Comment on Re: New behavior of 'each' with respect to references

Replies are listed 'Best First'.
Re^2: New behavior of 'each' with respect to references
by ikegami (Patriarch) on May 17, 2011 at 18:07 UTC

    keys(@a) returns the keys of the array elements: 0..$#a
    values(@a) returns the values of the array elements: @a

    Same for unblessed array references.

[reply]
[d/l]
[select]
      Which just adds to the badness, since it's apparently not consistent with exists. This is 5.10: 
      % perl -le '@a=0..4; delete $a[1]; print exists($a[1])||0'
0

      [download]
      So the key "1" is present, but $a[1] doesn't exist...

      If just the auto-dereference of hashes had been added (and it had worked with tied scalars overloading %{}, and it didn't give some BS can't-turn-it-off error about "breaking encapsulation" like "smart" match does for blessed hashrefs (I don't have 5.14 ATM, so I'm not sure on this part)), it would probably be fine, but auto-dereference combined with broken acceptance of arrays just seems like a disaster.

[reply]
[d/l]
[select]

        So the key "1" is present, but $a[1] doesn't exist...

        Backwards. The element does exist even though exists says otherwise. (exists returns information about internal memory allocation.) This bug is why the use of exists is deprecated on array elements.

        it's apparently not consistent with exists.

        Being inconsistent with a buggy and deprecated feature is of no importance to me.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom