Re^4: shift vs @

But it doesn't prevent me from being human and making a mistake.

Ok, firstly, you said that you can't easily do what you wanted, not that it was easy to make a mistake.

Secondly, attempting my $x, $y = @_ with strict in place (which is best practice anyhow) produces:

Global symbol "$y" requires explicit package name
[download]

Which would be a pretty big clue to me that something was wrong (you aren't creating a lexical $y with my $x, $y). Doing the same thing with warnings turned on (another best practice) results in:

Parentheses missing around "my" list
[download]

I'd say that pretty well prevents you from making this mistake, anyhow.

<–radiant.matrix–>
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

Comment on Re^4: shift vs @_ Select or Download Code

Replies are listed 'Best First'.
Re^5: shift vs @_ by exussum0 (Vicar) on Oct 06, 2006 at 20:01 UTC
Frequently, I use strict and warnings, but there are times I don't. And sometimes prototypes become production code. They get copy pasted by some mad madness. It's possible to also do my $x = @_, which will work w/ strict and warnings. Unless I have a good reason, I prefer shifts. It's just a preference as defensive programming. 'cause one day, somehow a my $x, $y = @_, and someone will forget to use strict. And I'll be part blame for the assignment, someone else for the warnings and strictness.	[reply]

Replies are listed 'Best First'.

Re^5: shift vs @_
by exussum0 (Vicar) on Oct 06, 2006 at 20:01 UTC

Unless I have a good reason, I prefer shifts. It's just a preference as defensive programming. 'cause one day, somehow a my $x, $y = @_, and someone will forget to use strict. And I'll be part blame for the assignment, someone else for the warnings and strictness.

[reply]