Right, but the Python person I was talking to said that for their reading, the explicit assignment to $_ made a lot more sense to him than implying it from a for loop. Again, a Python person, "explicit is better than implicit". However, to be honest, I like explicit setting of $_ better than a for loop. So much cleaner IFF you really are using only one value. In fact, I would improve this code with
SWITCH:{local$_='foo';...
And I think I avoid the lexical issues with the local modifier, yes?
Sure, use a label and then the last statement of your conditions can say last SWITCH;.
If you like your Perl more “Pythonic” then go for it. Personally I prefer to adopt language idioms rather than adapt one language to another. Similar arguments have occurred about C-style for ( ; ; ) loops vs. foreach loops that eschew an index variable when it’s not necessary.
There’s an old saying: “You can write FORTRAN in any language.” The Sapir-Whorf hypothesis says that language influences thought. Limiting yourself to the idioms of one language means limiting yourself to solutions that can be expressed in it, and that doesn’t make sense if you’re actually using a different language.
Agreed. But some idioms can be improved. I think the explicit $_ assignment is better than the side-effect assignment via a for (each) statement that has only one target. And yes, in the production code, I added a SWITCH: label. However I did not change last; to 'last SWITCH;; I think that's too verbose, and it doesn't impedance-match withbreakin traditionalswitch` statements.
The issue is not that it's lexical, but that assigning to a lexical $_ instead of the superglobal $_ broke assumptions that people make that $_ can be used in other code scopes dynamically, such as subroutines you call. If it had started out being lexically aliased by foreach and map it would lead to safer code overall.
local assignment does avoid some danger of action at a distance from aliasing with foreach; in the following code, if some_sub were to assign anything to $_ it would clobber $var as well.
my$var='foo';foreach($var){some_subandlast;}
In the end I always recommend using a few more keystrokes and avoiding $_ for this entirely.
I whipped up two quick tests: gist.github.com/matthewpersico/aa1... and gist.github.com/matthewpersico/aa1... and yes, not having that local can be disastrous. So, since for and map and the like are coded "properly", i.e., they localize $_, you should be safe to use them and use functions that call them. But if someone has done this $_ assignment trick and forgets the local, there be dragons.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Right, but the Python person I was talking to said that for their reading, the explicit assignment to
$_made a lot more sense to him than implying it from aforloop. Again, a Python person, "explicit is better than implicit". However, to be honest, I like explicit setting of$_better than a for loop. So much cleaner IFF you really are using only one value. In fact, I would improve this code withAnd I think I avoid the lexical issues with the
localmodifier, yes?Sure, use a label and then the last statement of your conditions can say
last SWITCH;.If you like your Perl more “Pythonic” then go for it. Personally I prefer to adopt language idioms rather than adapt one language to another. Similar arguments have occurred about C-style
for ( ; ; )loops vs.foreachloops that eschew an index variable when it’s not necessary.There’s an old saying: “You can write FORTRAN in any language.” The Sapir-Whorf hypothesis says that language influences thought. Limiting yourself to the idioms of one language means limiting yourself to solutions that can be expressed in it, and that doesn’t make sense if you’re actually using a different language.
Agreed. But some idioms can be improved. I think the explicit
$_assignment is better than the side-effect assignment via afor (each)statement that has only one target. And yes, in the production code, I added aSWITCH:label. However I did not changelast;to 'last SWITCH;; I think that's too verbose, and it doesn't impedance-match withbreakin traditionalswitch` statements.The issue is not that it's lexical, but that assigning to a lexical
$_instead of the superglobal$_broke assumptions that people make that$_can be used in other code scopes dynamically, such as subroutines you call. If it had started out being lexically aliased byforeachandmapit would lead to safer code overall.localassignment does avoid some danger of action at a distance from aliasing withforeach; in the following code, if some_sub were to assign anything to$_it would clobber$varas well.In the end I always recommend using a few more keystrokes and avoiding
$_for this entirely.I whipped up two quick tests:
gist.github.com/matthewpersico/aa1... and gist.github.com/matthewpersico/aa1... and yes, not having that
localcan be disastrous. So, sinceforandmapand the like are coded "properly", i.e., theylocalize$_, you should be safe to use them and use functions that call them. But if someone has done this$_assignment trick and forgets thelocal, there be dragons.