Front page | perl.perl5.porters |
Postings from December 2010
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.
Abigail
Thread Previous
|
Thread Next