New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no warnings "module name" #11888
Comments
From @cpansproutperldiag lists some warnings in the ‘overload’ category. What is not documented anywhere is that this is a custom category registered by overload.pm. The result: $ ./perl -Ilib -e 'use warnings; no warnings "overload"; ...' If I load overload.pm first, it works fine. While this could be argued as not being a bug, it just doesn’t feel right. It should be possible to disable a warnings category before it is registered, because usually the code disabling the warnings category doesn’t know when it is registered. Flags: Site configuration information for perl 5.15.6: Configured by sprout at Mon Jan 16 08:41:41 PST 2012. Summary of my perl5 (revision 5 version 15 subversion 6) configuration: Locally applied patches: @INC for perl 5.15.6: Environment for perl 5.15.6: |
From @cpansproutOn Sun Jan 22 12:52:17 2012, sprout wrote:
Also, ‘use warnings’ doesn’t enable overload warnings unless overload.pm -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Sun Jan 22 12:52:17 2012, sprout wrote:
Also, ‘use warnings’ doesn’t enable overload warnings unless overload.pm -- Father Chrysostomos |
@cpansprout - Status changed from 'new' to 'open' |
From zefram@fysh.orgFather Chrysostomos wrote:
We could implement that by implicitly registering any warnings So I think we have to insist on explicit registration. A module that
That sounds more like a real bug. It needs to be addressed by changing -zefram |
From zefram@fysh.orgI wrote:
Fixed in commit 006c1a1. It turned -zefram |
From @cpansproutOn Nov 15, 2017, at 1:59 AM, Zefram via RT <perlbug-followup@perl.org> wrote:
Yes, that’s prceiesly why I didn’t go aehad and imlpemnet it. (Sutides sohw that, as long as the frsit and lsat ltteres are in the rihgt plcae, poelpe can stlil raed qucilky.) It was a conundrum I did not know how to resolve.
I want to avoid this, though: use warnings; or: use warnings; Do you think it would be reasonable to add a REGISTER directive, similar to FATAL? use warnings;
Thank you for fixing that. |
From @xsawyerxOn 11/19/2017 09:07 PM, Father Chrysostomos wrote:
Please don't. This mixes the import specification for warning categories
Not as bad, but worries me about action at a distance.
I'll second that. :) |
From @cpansproutOn Sun, 19 Nov 2017 12:47:25 -0800, xsawyerx@gmail.com wrote:
I think you are missing the fact that these two examples are what currently work to get around the problem. We already conflate package names with warning categories.
Warning registrations are necessarily global. This is no more action at a distance than the existing: package Foo; -- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos wrote:
That's nasty. warnings::register is a shortcut for the common case of
This is what I envisioned, and I think it's the pattern to favour.
Strikes me as confusing. What does it do to the Hash::Util category, Registering someone else's warning category is an unusual requirement. -zefram |
From @cpansproutOn Mon, 20 Nov 2017 01:56:20 -0800, zefram@fysh.org wrote:
I think you are right. It is confusing.
It’s not that unusual if you consider that it was because of overload.pm that I filed this ticket to begin with. At the very least, can we make warnings.pm register the overload category, or make overload a core category? I want to avoid this, which is not very maintainable: use warnings; -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Mon, 20 Nov 2017 01:56:20 -0800, zefram@fysh.org wrote:
I think you are right. It is confusing.
It’s not that unusual if you consider that it was because of overload.pm that I filed this ticket to begin with. At the very least, can we make warnings.pm register the overload category, or make overload a core category? I want to avoid this, which is not very maintainable: use warnings; -- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
If we do that for overload, why not for others? Where do we draw -zefram |
From @cpansproutOn Wed, 13 Dec 2017 12:32:58 -0800, zefram@fysh.org wrote:
overload.pm, like strict and warnings, is a core feature. The functionality these modules provide is not actually implemented in the modules themselves, but is part of perl. That overload.pm registers its own warnings category and uses warnings::warnif is just an implementation detail. Its warnings are even listed in perldiag under the ‘overload’ category. Hence, I think it is sufficiently part of the language itself, and not just another module. -- Father Chrysostomos |
Migrated from rt.perl.org#108778 (status was 'open')
Searchable as RT108778$
The text was updated successfully, but these errors were encountered: