As far as $_, I think that the problem of the many uses can be overcome by simply doing
{
local $_;
# stuff...
}
.
I haven't seen this do anything too weird, and it provides a good way to overwrite $_ temporarily. It sort of reminds me of elisp's (save-excursion ...) Anyway, here's my answers to the questionnaire -- favorites are first.
| (Least) Favorite Perl Instruction | local; reset | See above. Why reset? Too dangerous, especially when you've got tons of single-char vars. |
| (Least) Favorite Looping Mechanism | {}; for | Naked blocks give you more flexibility. for just seems useless to me. |
| (Least) Favorite Module | Data::Dumper; | Dump those objects! No least favorite -- I sort of like them all. |
| (Least) Favorite Special Var | $_; $] | $_ is so useful. $] is not. |
| Favorite Var Type | typeglob | Very obfuscatable. |
| (Least) Favorite Command Line Switch | -e; -U | -e allows me to do one-liners. -U does unsafe things. |
| Favorite Pragma | use strict; no strict "refs"; | Good for bugcatching, except when I want to use symbolic references. |
| Favorite Regexp {Modifier,Metachar} | i; \Q | Yes to i! Too much work to manually decapitalize all the time. \Q useful for when arbitrary data comes in which you need to match. |
| Favorite Descriptive Var Name | %z | Not very descriptive, but I like it nonetheless. |
| Favorite HERE doc delimiter | print; | Or some other command... |
| Favorite Filehandle | FOO | Should be obvious why... |
| [reply]
[d/l] |
The majority of the problems can indeed be solved that
way. (Though good luck if you forget a local anywhere.)
But there are more subtle maintainability issues with
implicitly passing data in global variables. Code that
is explicit about where data that is being acted on came
from is better than code which hides that information
elsewhere.
This is also why I dislike local. Oh, I know when to use
it and I do use it correctly. But I prefer not needing it.
Perl has too many scoping mechanisms whose interactions are
too baroque. Rather few people really understand it, and
when people are working with interfaces they don't
understand they get confused and make mistakes. (Often
without knowing that they made mistakes.) As the
documentation says, local is probably not what you wanted
to use, my is generally more appropriate...
| [reply] |
Good point. However, I still disagree. You're right about the unmaintainability (though it fits in nicely with some of my patterns of obfuscation). I prefer local being there though -- I think that it has perhaps more uses than my does.
Then again, TMTOWTDI... take your pick.
Drake Wilson
| [reply]
[d/l]
[select] |
