Glenn Linderman wrote:
On approximately 7/2/2005 4:56 PM, came the following characters from
the keyboard of Robert May:
In several places in Win32::GUI XS code there are warnings printed.
When this happens, there is (as far as I have checked) always test
'if (PL_dowarn)' around the warning. Now, I'm sure there is some
Perl history here, as the documentation (perlintern) clearly states
that PL_dowarn is the XS programmer's equivalent of $^W. It is
not! PL_dowarn is a bitmask that conveys a whole load of global
warning state (See perl's warnings.h for more details). The upshot
of this is that the *only* way to silence such messages from
Win32::GUI is to ensure that you start perl with no warning command
line switches (none of -w, -W or -X) and to not have a 'use warnings'
line anywhere in your code. {Yes, currently -X on the command line
results in Win32::GUI splitting out warnings :-) (you can also use a
$SIG{__WARN__} hook, but you need to know the characteristics of the
messages you want to silence to do this - see my recent post to the
users list).
This is obviously an undesirable situation.
Using (PL_dowarn G_WARN_ON) instead is the direct equivalent of
checking $^W. The downside of this is that 'use warnings' does not
set $^W, and so making this change will result in most current code
silencing these warnings. To turn them on you need to use -w, -W
(command line) or $^W=1 (in your code). But at least we'd have a
way to control whether such messages are emitted.
I see 4 possible ways forward:
(1) Leave it as it is, and wait for Perl 5.9 which will (from what I
read) extend the 'warnings::warnif' mechanism to XSUBS.
(2) Change to checking against (PL_dowarn G_WARN_ON), with the side
effects mentioned above, and highlighting the change in release
notes/readme.
(3) Introduce a package global (Win32::GUI::WARNINGS?) that the user
can set to control warnings, defaulting to on (matching the current
behaviour)
(4) Review the warnings that we have, and decide if they are needed,
or if there are other ways to behave. (for example the irritating
warnings about -style being deprecated could perhaps be removed, as I
think it is a useful option). This route may be orthogonal to the
other 3, as we may want to do this anyway, and if we have any
warnings left, then we will still need to pick one of the other 3
options.
My vote is for (2). Comments?
Not clear that I understand the various Perl warning mechanisms you
describe to comment effectively.
I'm not surprised. They are complex, and not well documented. It's
taken we most of the week to get my current (very poor) understanding of
how it all works. I'm entering a busy spell at work, so I'm not sure
exactly when, but I'll try to find time to write up my understanding a
bit better at a later date.
Here are a couple of threads that seem to be the information 'from the
horses mouths', so to speak. They're pretty impenetrable, and I put the
link here more so that I can find them later, than because I think they
are a good read.
http://groups.google.co.uk/group/perl.perl5.porters/browse_thread/thread/5638f7d32139d3a4/368fb93c71813e02?q=lexical+warnings+XSUBhl=en#368fb93c71813e02
http://groups.google.co.uk/group/perl.perl5.porters/browse_thread/thread/d26aec8d5376d9ca/e2713a92344a5df9?q=lexical+warnings+XSUBrnum=5hl=en#e2713a92344a5df9
I do use warnings and -w in most of my code, and all is well for
me, and I get lots of diagnostics... And I haven't had any major
problems coding around the existing warnings, such that my code
doesn't cause warnings to occur. So (1) seems acceptable to me.
I don't understand the side effects of (2).
There would be no change for you. The change would be for anyone who
doesn't use '-w' - Win32::GUI's warnings would stop appearing, as there
is no way to reliably check from XS what the 'use warnings' settings in
the caller's scope are set to.
(3) seems too specific to this module.
Indeed. But not having a way to turn off warnings in production code is
an issue, isn't it?
(4) A review of warnings is certainly not a bad thing... but proposed
changes should be entertained with caution. -style is easy but I
think the theory under which it was deprecated is that it can be too
easily used to turn off things that default to on, that you might not
know about. This is because (I think) of the way that Microsoft
introduces more options, some of which are on. So adding and removing
specific options seems better, according to that theory.
Right, I understand why -style is dangerous. But without it you have to
have knowledge of what styles Win32::GUI uses by default so that you can
pop the ones you don't want, and add the ones that you do want. In the
case where you know exactly what styles you want it is equally dangerous
to use pop and push in a module, as any changes to the default styles
used by Win32::GUI may break
