in reply to Re: Should Test::Most import strict and warnings?
in thread Should Test::Most import strict and warnings?

These modules which enable strict for the caller reduce the number of modules which appear to use strict, which can send the wrong message to/confuse people who are learning perl by reading this code which has strictures enabled but does not advertise the fact by including "use strict".

If you apply that argument fully, you have to argue against any module which performs non-obvious changes to calling packages through import(), including autodie and perl5i and (probably) utf8.

You probably also have to ignore the line in the Modern::Perl documentation which says "Don't use this in your own CPAN modules; there are better ways to enforce this mechanism."

Me, I think it's more important to teach novices how to understand code than to coddle them into some sort of ignorant pseudo-understanding based on skimming it and guessing at what it does. perldoc should be ready at hand.

Replies are listed 'Best First'.
Re^3: Should Test::Most import strict and warnings?
by duelafn (Parson) on Feb 08, 2010 at 18:01 UTC

    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

[reply]
[d/l]
[select]
      Typing 5 extra lines listing explicitly the modules I want to use is not considered "difficult" by me.

      Five extra lines in every file, at least one extra line in every method, and pretty soon you have a lot more code than you need.

[reply]
        Define "a lot." 5 lines per file and 1 line per function is at worst 150 percent more code (with one-line functions and one-function modules). If you're dumb enough to write code like that, I don't want to use it. If your code imports random modules into my code, I don't want to use it. If you can't either type out your boilerplate of choice or get your editor to do it for you, you probably shouldn't be a programmer.

        Your acolytes will use "chromatic::Perl" (evidently a pragma...). Other people don't want your religion.

[reply]

In Section Seekers of Perl Wisdom