Don't turn back on warnings that I've turned off
Hi, At $WORK we have a codebase that’s currently running under perl 5.14.2 that we want to move to perl 5.20.3. (Can’t use 5.22 because, via another module that we use, we use Coro, which blows up spectacularly if you’re running a version of Perl that the author of Coro disapproves of.) The codebase makes regular use of smartmatch (albeit only in the “match a variable against this array” sense). This produces warnings in modern Perls, so my plan was to extend our standard “enable all pragmas according to house policy” module to disable experimental::smartmatch warnings, under Perls that are known to warn about this but still implement it in the same way. That gives us a year or two to get rid of it once p5p decide what they’re going to do with smartmatch. Unfortunately, Dancer turns the warnings back on. Even if you’d previously disabled them. I can understand saying “if you haven’t enabled warnings, you really should have, so Dancer is going to enable them for you”. I can also understand people saying “use Dancer” and expecting warnings to be enabled, so they don’t have to explicitly say “use warnings”. That’s fine. But if I’ve explicitly enabled most but not all warnings, Dancer shouldn’t trample all over that. As it is, I have to write this to avoid warnings: #!/usr/bin/env perl use 5.20.1; no warnings 'experimental::smartmatch'; no warnings 'uninitialized'; use Dancer qw(:syntax); no warnings 'experimental::smartmatch'; no warnings 'uninitialized'; my $foo = shift; given ($foo) { when ('foo') { say "This is foo, the King of variable names"; } when (['bar', 'baz']) { say "A lesser pretender $_"; } default { say "$_ is dead to me"; } } This is a toy example just to make the point: rather than that one use Dancer statement I could have a whole bunch of use statements, and Dancer could have been pulled in by some other module, possibly not even something I imported directly. Now, I could get rid of one line in the example above by saying no warnings::anywhere ‘uninitialized’; as that would turn that warning off globally, but warnings::everywhere doesn’t work with compile-time pragmas. Is there a way to find out whether the calling package has enabled warnings, and if so don’t enable all of them again? Because that would be ideal. Sam -- Website: http://www.illuminated.co.uk/
What version of Dancer are you using? The behavior changed in v1.3111 when the import_warnings config setting (import warnings by default) was replaced by global_warnings (don't import warnings by default). See https://metacpan.org/pod/Dancer::Config#global_warnings-boolean-default:-fal... I get no warnings for the following app with Dancer 1.3138, using the default config file: package MyApp; use Dancer ':syntax'; no warnings 'uninitialized'; get '/' => sub { my $foo; print $foo; }; true; On Tue, Sep 15, 2015 at 2:55 PM, Sam Kington <sam@illuminated.co.uk> wrote:
Hi,
At $WORK we have a codebase that’s currently running under perl 5.14.2 that we want to move to perl 5.20.3. (Can’t use 5.22 because, via another module that we use, we use Coro, which blows up spectacularly if you’re running a version of Perl that the author of Coro disapproves of.)
The codebase makes regular use of smartmatch (albeit only in the “match a variable against this array” sense). This produces warnings in modern Perls, so my plan was to extend our standard “enable all pragmas according to house policy” module to disable experimental::smartmatch warnings, under Perls that are known to warn about this but still implement it in the same way. That gives us a year or two to get rid of it once p5p decide what they’re going to do with smartmatch.
Unfortunately, Dancer turns the warnings back on. Even if you’d previously disabled them.
I can understand saying “if you haven’t enabled warnings, you really should have, so Dancer is going to enable them for you”. I can also understand people saying “use Dancer” and expecting warnings to be enabled, so they don’t have to explicitly say “use warnings”. That’s fine.
But if I’ve explicitly enabled most but not all warnings, Dancer shouldn’t trample all over that.
As it is, I have to write this to avoid warnings:
#!/usr/bin/env perl
use 5.20.1; no warnings 'experimental::smartmatch'; no warnings 'uninitialized';
use Dancer qw(:syntax);
no warnings 'experimental::smartmatch'; no warnings 'uninitialized';
my $foo = shift; given ($foo) { when ('foo') { say "This is foo, the King of variable names"; } when (['bar', 'baz']) { say "A lesser pretender $_"; } default { say "$_ is dead to me"; } }
This is a toy example just to make the point: rather than that one use Dancer statement I could have a whole bunch of use statements, and Dancer could have been pulled in by some other module, possibly not even something I imported directly.
Now, I could get rid of one line in the example above by saying
no warnings::anywhere ‘uninitialized’;
as that would turn that warning off globally, but warnings::everywhere doesn’t work with compile-time pragmas.
Is there a way to find out whether the calling package has enabled warnings, and if so don’t enable all of them again? Because that would be ideal.
Sam -- Website: http://www.illuminated.co.uk/
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
I get no warnings for the following app with Dancer 1.3138, using the default config file:
package MyApp; use Dancer ':syntax'; no warnings 'uninitialized';
get '/' => sub { my $foo; print $foo; };
I get this with Dancer and Dancer2, and I should have been clearer. There are two things that are in violent conflict here. The first is the instinct to turn pragmas on as soon as possible. For all of its many, many faults, Perl::Critic is right to say that you should say use strict as soon as possible, so muscle memory pretty much requires that you start typing this for every new script or module: use strict; use warnings; no warnings ‘uninitialized’; no warnings ‘experimental::smartmatch’; If this was a standalone script I’d have added a shebang at the start, and possibly a use lib, but otherwise it’s the same idea: start off with a blank slate, say what you want to happen system-wide, then pull in various CPAN and/or private modules, then write your own code. (At $WORK we have a module called our::way which does all of this for us, so you just say use our::way at the start and it enables strictures, most warnings, UTF8 mode etc.) What’s in conflict with this approach is that if I say use Dancer - or I import a module, directly or indirectly, that says use Dancer qw(:syntax) or something - then all of my warnings are reset. So I have to say no warnings ‘experimental::smartmatch’ again. It’s not just Dancer that does this - I believe Moose and Moo also do it. But it’s still annoying and rude. Sam -- Website: http://www.illuminated.co.uk/
2015-09-16 1:05 GMT+03:00 Sam Kington <sam@illuminated.co.uk>:
It’s not just Dancer that does this - I believe Moose and Moo also do it. But it’s still annoying and rude.
I think it was just bad idea to turn those features experimental after so many years of active and wide use. It pays off in so many places. Wbr, -- Kõike hääd, Gunnar
On 2015-09-15 9:20 PM, WK wrote:
2015-09-16 1:05 GMT+03:00 Sam Kington <sam@illuminated.co.uk>:
It’s not just Dancer that does this - I believe Moose and Moo also do it. But it’s still annoying and rude.
I think it was just bad idea to turn those features experimental after so many years of active and wide use. It pays off in so many places.
If you're talking about the "smartmatch" or "given-when" introduced in Perl 5.10, it was actually a superbly GOOD idea that they were turned experimental. These features were broken and troublesome from day one, and should have been marked experimental from the start, had the 'experimental' feature existed. Marking them such now makes it possible to eventually fix or remove those broken features, while giving people time to not use them or know what they're getting into if they do. I also don't think they were actively and widely used, or not anywhere close to features that existed in Perl prior to 5.10. -- Darren Duncan
participants (4)
-
Darren Duncan -
Maxwell Carey -
Sam Kington -
WK