On Mon, 04 Aug 2003 07:03:02 -0400, John Peacock <[EMAIL PROTECTED]>
wrote:
>Jan Dubois wrote:
>> Consider you were applying bug fixes to your libgtk-1.2 library and now
>> Mozilla starts displaying popups: "Property 'foo' of Widget 'bar' is
>> deprecated and will be removed in libgtk-1.3". The Gtk developers would
>> say: "We can't remove property 'foo' if we don't give people some warning
>> so that they have a chance to fix their code before it is gone".
>
>This is, IMNSHO, a straw man argument. The deprecation warning only appears
>when '-w' or 'use warnings' are in effect. They won't even display for CGI
>code, except in the error log (assuming the developer didn't forget to disable
>warnings to the browser). Are all of the programs you are concerned about '-w'
>enabled?
Yes, they all have -w on the #! line. I guess you will argue that this is
a bad idea. However, the software is extensively tested *not* to display
any warnings under normal operations. So whenever a warning is being
displayed, it typically indicates a bug in the program. Although pretty
rare, this has helped to track down a few problems with the code.
Note that the Perl documentation strongly encourages users to use '-w' in
all their code. perl.pod argues that it is a bug that it is not the
default. There is no mention in the warnings.pm module that you should
*not* use it in production code. Currently I think it would need a
comment like:
If you use the warnings pragma in production code, make sure you
always disable deprecation warnings, because they may be introduced
at any time:
no warnings 'deprecated';
But that would defeat the purpose: people would forget to reenable the
deprecation warnings during development and never see them. How should
CPAN modules deal with this? Not use 'warnings' at all? The whole
warning system doesn't really work if you can arbitrarily introduce new
warnings during maintenance updates.
Adding this deprecation warning to 5.8.1 will affect several 1000 users,
and actually break applications for a few hundred of them if they were to
upgrade from 5.8 to 5.8.1. This may be a strawman to you, but it is a
real concern to me. We can always work around it by removing the warning
just from ActivePerl 5.8.x. But I still think that it shouldn't go into
Perl 5.8.1 either.
Cheers,
-Jan
