On Thu, Oct 28, 2010 at 08:40:14PM +0100, John wrote: > On 28/10/2010 13:42, Jesse Vincent wrote: >> >> >> On Wed, Oct 27, 2010 at 03:42:44PM -0700, David Golden wrote: >> >>> # New Ticket Created by David Golden >>> # Please include the string: [perl #78656] >>> # in the subject line of all future correspondence about this issue. >>> #<URL: http://rt.perl.org/rt3/Ticket/Display.html?id=78656> >>> >>> >>> This patch updates all functions that operate directly on array or >>> hash containers to also accept references to arrays or hashes: >>> >>> push $arrayref, @stuff; >>> unshift $arrayref, @stuff; >>> pop $arrayref; >>> shift $arrayref; >>> splice $arrayref, 0, 2; >>> keys $hashref; # or $arrayref >>> values $hashref # or $arrayref >>> ($k,$v) = each $hashref # or $arrayref >>> >>> >> +1 - Unless someone comes up with a partticularly damning problem with >> this, I'd love to see it get in for the next blead release. >> >> >> > My damming problem with this is you have pushed a compile time syntax > error, that I can test with perl -c, being that push et all expect the > next none white space character to be a '@' to a run time check. that I > have to now run the code on in order to check I am getting the correct > reference passed in. No, he didn't. He did not make push @$ref illegal. Nor push @foo. By all means, if you like the checking 'push @' or 'keys %' give you, keep using it. Now, if you say "yeah, but I typically have both '@foo' and '$foo' in my program, and I often type '$' where I meant '@'", then be aware, push @array => $foo; # Oops I meant @foo now is neither a compile-time, nor a run-time error. And it won't change with Davids patch either. And you currently won't get a compile-time error on push @$coderef, 1, 2, 3; either. AbigailThread Previous | Thread Next