Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Should Test::Most import strict and warnings?

by Ovid (Cardinal)
on Feb 05, 2010 at 11:40 UTC ( #821543=perlquestion: print w/ replies, xml ) Need Help??
Ovid has asked for the wisdom of the Perl Monks concerning the following question:

I think I want Test::Most to also provide strict and warnings for people. I've mentioned this on blogs.perl.org and on Perl-QA. I've had three positive comments and no negative ones. In short, instead of this boilerplate at the top of all of your tests:

use strict; use warnings; use Test::Most tests => 34;

You just need this:

    use Test::Most tests => 34;

I hate boilerplate and this will ease it. The only thing which gives me pause is that this module has become rather popular. It has over 800 passes for the latest release and CPANTS shows more and more modules depending on it. In short, if I've missed something, I could break a lot of code.

Given that those who use Test::Most are guaranteed to have the warnings pragma available (Test::Exception uses it and Test::Most uses that), I think we're safe there. If people don't want strict and warnings, they would have to now be explicit about this intention rather than forget to use these pragmas:

use Test::Most tests => 4; no strict; no warnings;

I think this is a sane change, but I can see that it might be controversial. My major concern, though, is to understand if I'm likely to break a lot of code.

Comment on Should Test::Most import strict and warnings?
Select or Download Code
Re: Should Test::Most import strict and warnings?
by JavaFan (Canon) on Feb 05, 2010 at 12:32 UTC
    I'd say no. Why would Test::More turn on strict and warnings in the calling scope? Many people consider having a non-empty @EXPORT (and hence, a default export if no argument to use Module are given) to be rude - why would by default turning on strict/warnings in the calling scope be any different? It's also invisible, unexpected magic. I don't like invisible, unexpected magic. People aren't used that strict or warnings is on if there isn't a visible use strict, use warning. Invisible magic is hard to debug if you don't know about it. And why Test::More? Why not My::Funky::Module?
        Test::Most, not Test::More. That's a very important difference here.
        Sorry, I'm just used to typing Test::More.

        But that doesn't change my arguments. I wouldn't want any module to turn on a pragma in the calling scope - unless that is its specific purpose. turn::on::all::pragmata should turn it on. But not something from the Test::* namespace.

Re: Should Test::Most import strict and warnings?
by bellaire (Hermit) on Feb 05, 2010 at 13:53 UTC
    Is there precedent for this? It does seem a little odd that a module would enable pragmas in its calling scope when they aren't strictly necessary (no pun intended). I can appreciate that it reduces boilerplate, but there's nothing about the stated purpose of Test::Most that makes it obvious that you'd be doing this by default. Most of us are used to having to turn on strict and warnings in our own code. I think your module's user population would break down like this:
    • (Hopefully) most people are already using strict and warnings in calling scope, so this change is transparent but provides no tangible benefit.
    • Some people are not using strict and warnings in calling scope, so this change breaks their code and they add no pragmas to get their code to work again, again no benefit.
    • A small number of people already using strict and warnings read about this change and are able to reduce their boilerplate code by two lines, for the benefit stated.
    • An even smaller number of people (perhaps zero) have their code break and they decide to make it strict- and warnings-compliant. I guess this is a benefit, but it's not your stated intention.
      Is there precedent for this?

      iirc Moose enables strict in the caller's scope.

      Still I'm not in favour of entagling policy and implementation.

      Perl 6 - links to (nearly) everything that is Perl 6.
Re: Should Test::Most import strict and warnings?
by chromatic (Archbishop) on Feb 05, 2010 at 18:35 UTC
    My major concern, though, is to understand if I'm likely to break a lot of code.

    The question is the same as for any other API change. Given that Test::Most exists to reduce boilerplate, reduce boilerplate.

      Given that Test::Most exists to reduce boilerplate, reduce boilerplate.

      Hear, hear

      -stvn
Re: Should Test::Most import strict and warnings?
by duelafn (Priest) on Feb 06, 2010 at 15:52 UTC

    Blah, <rant>I'm not a fan of these micro-packages that try to save boilerplate, they just add add perldoc lookups when reading code with "Favorite::Boilerplate::Saving::Module::OfTheWeek" and add pointless dependencies.</rant>

    Getting back on topic: 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"

    I can (just) swallow it for Moose (which could probably be a pragma itself anyway), but don't like it in general.

    Good Day,
        Dean

      I'm not a fan of these micro-packages that try to save boilerplate ...
      These modules which enable strict for the caller reduce the number of modules which appear to use strict ...

      I couldn't agree more about the micro-package thing, I think this does add a layer of confusion to those new to the perl community. Especially since it seems to have brought out the bad side of TIMTOWTDI, with all the different variations. For instance, Modern::Perl is 5.10 (or above) only, imports warnings and strict and sets the MRO to use c3. While common::sense imports only some strictures (vars & subs), a select few 5.10 features, a handful of warnings AND makes all warnings FATAL (this, for those who don't know, escalates all warnings to fatal errors). These two modules seem to have similar goals, but end up changing your environment in sometimes radical and sometimes subtle ways.

      However, I do not agree when talking about non-micro-packages like Test::Most.

      I can (just) swallow it for Moose (which could probably be a pragma itself anyway), but don't like it in general.

      Well, I think you can likely swallow it easier because all Moose does is to turn on strict and warnings. Basically reproducing the effect of the "use strict; use warnings;" boilerplate that most people have been using (and the community at large has been advocating) for at least the past 7 or 8 years now. You can still turn any strictures or warnings off lexically if you want too, but for the most part, Moose just sets up the environment that the majority of people have been using for a long time now. And basically, that is what Ovid is proposing Test::Most do as well.

      Also, I am curious as to why you think Moose should be a pragma? Pragmas typically just twiddle with the guts of Perl some and then let you go about your business. Moose turns the guts of Perl inside-out, twists them around all meta-circular-like, sprinkles on some sugar and then sticks around to make sure you don't cut off a limb or two.

      -stvn
        non-micro-packages like Test::Most.

        Test::Most is a bit confused in that it provides both real functionality as well as the "micro-package" features. If Test::Most were split (only hypothetically, I'm not so much suggesting that it do so) into Test::Most::Features and Test::Most::ImportOtherPackages (where the strictures enforcing would be placed), then my beef is with Test::Most::ImportOtherPackages, and not with Test::Most::Features.

        I am curious as to why you think Moose should be a pragma?

        pragma (meaning just "all lower-case name") modules advertise "something more than simple function importing is happening here". Aside from enabling strict, I believe, Moose accomplishes everything it does via simple sub imports (no overwriting of core functions, ...) so strictly speaking it should not be a pragma. However, it does feel a lot more magical than a plain module, and it imports subs which further create/import more subs which feels like it is extending the syntax of perl... Thus, I would accept arguments that it could have been named all-lower. Though I am not necessarily arguing that it should have.

        Good Day,
            Dean

      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.

        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

Re: Should Test::Most import strict and warnings?
by BrowserUk (Pope) on Feb 06, 2010 at 18:34 UTC

    I don't use Test::*, so give my opinion on this just as much weight as it deserves.

    But would you fit a sound system in your car, that forced you to wear your seatbelt when you listen to it?

      I don't use Test::*....

      That explains your analogy. Let me fix it for you:

      Would you have a new braking system installed in your car if they also upgraded your airbags?

        Not unless there was something wrong with the old one.

        "Would you have a new braking system installed in your car if they also upgraded your airbags?"

        Would not that analogy imply that there could be something possibly wrong with the new braking system that may require better airbags.

      I believe you've mentioned before that you don't use Test:: modules, but I can't find that response and I can't remember what you say you do to verify your code works correctly. Could you refresh my memory? I'm curious to know what other strategies people apply.

Re: Should Test::Most import strict and warnings?
by shmem (Canon) on Feb 20, 2010 at 13:20 UTC

    In my shell rc file, I do have

    alias strict="export PERL5OPT='-Mstrict -Mwarnings'" alias nostrict='unset PERL5OPT'

    and done.

    But that's just me. I wouldn't impose that on others. I wrote and write modules which do use strict and warnings, but those are just my modules. I wouldn't impose that on the caller.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://821543]
Front-paged by broomduster
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (9)
As of 2014-08-28 00:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (254 votes), past polls