Well, yes, I would be against perl5i and Modern::Perl (sorry). I find autodie and utf8 acceptable (note, both are all-lower names) primarily due to their very limited focus — they each do one thing for me not several things that are all related to each other only by way of being good for me. It is important to me that autodie limits itself to modifying built-in functions, and I would be opposed to autodie enabling strict.
I'm all in favor of understanding over coddling, but constant worry about what strange things a normal looking module might do is not fun me or the newbie. perldoc should be ready at hand, but choosing long_descriptive_function_names is encouraged so that code skimming is possible, why should loading a standard-looking module be a minefield of potential (well-intentioned) "magic" (meaning anything other than importing a few subs)? Already there are those who discourage adding subs to @EXPORT, claiming that everything should be in @EXPORT_OK so that even imported functions are explicitly listed.
If Test::More were an all-lower named module it could get away with enabling strict, but a proliferation of lower-case modules is not good either — one should have a good reason for building one. And, yes, that means I have less opposition to common::sense than to Modern::Perl simply because the former advertises "something more than function importing happening here", but I would not use either and would rather not see either in any code I run across.
Update: Forgot to add that autodie and utf8 both provide a service that can be very difficult to do without them. Typing 5 extra lines listing explicitly the modules I want to use is not considered "difficult" by me.
Good Day,
Dean
In reply to Re^3: Should Test::Most import strict and warnings?
by duelafn
in thread Should Test::Most import strict and warnings?
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |