|
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.
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
| [reply] |
|
|
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.
| [reply] |
|
|
Given that Test::Most exists to reduce boilerplate, reduce boilerplate.
Hear, hear
| [reply] |
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? | [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
|
|
|
Re: Should Test::Most import strict and warnings?
by duelafn (Parson) 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.
| [reply] |
|
|
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.
| [reply]
[d/l] |
|
|
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.
| [reply] |
|
|
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.
| [reply]
[d/l]
[select] |
|
|
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.
| [reply]
[d/l]
[select] |
|
|
|
|
|
Re: Should Test::Most import strict and warnings?
by BrowserUk (Patriarch) 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?
| [reply] |
|
|
| [reply] |
|
|
| [reply]
[d/l] |
|
|
| [reply] |
|
|
"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.
| [reply] |
Re: Should Test::Most import strict and warnings?
by shmem (Chancellor) 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. | [reply]
[d/l] |
