Front page | perl.perl5.porters |
Postings from January 2012
On Tue, Jan 31, 2012 at 10:44:44AM +0100, Abigail wrote:
> On Mon, Jan 30, 2012 at 08:00:14PM -0500, David Golden wrote:
> > On Mon, Jan 30, 2012 at 6:57 PM, Ricardo Signes
> > <perl.p5p@rjbs.manxome.org> wrote:
> > > Please let me know whether I understand properly. Here is an example based on
> > > my understanding of your suggestion. Please note that, for the sake of
> > > simplicity, I have not included feature.pm behavior in this example.
> > >
> > > 1. We realize that adding foozles was a horrible mistake.
> > > 2. We add "foozles" to the Future Deprecations section of perl5200delta
> > > 3. In 5.21.0, we add the deprecation warning.
> > > 4. In 5.23.0, we remove foozles.
> >
> > Correct. With the annual release cycle, that's a two year period from
> > stable-release "notice of future removal" to stable-release "removal",
> > one year without warnings and one with.
>
>
> That makes me more happy than adding a deprecation warning as soon as we
> realize foozles was a mistake and is deemed to be removed.
I think I like this ordering better. First document it as a plan, then do
it. Not that *everyone* reads the documentation...
> It gives people a chance to act without being nagged on each and every
> run of the program. Now, it may be useful if there was a "predeprecation"
> category, which by default is *off* on a plain "no warnings;", in that case,
> we'd add a predeprecation warning for foozle in 5.19.0, and upgrade it to
> a deprecation warning in 5.21.0 (kind of like Yves plan, while keeping the
> current deprecation warning untouched).
I'm not sure what you're meaning by this last part. Deprecation warnings
aren't "mandatory" - they default to on but are disabled by "no warnings;":
$ ./perl -Ilib -e 'print defined %a'
defined(%hash) is deprecated at -e line 1.
(Maybe you should just omit the defined()?)
$ ./perl -Ilib -e 'no warnings; print defined %a'
$
A predeprecation warning makes sense, sort of. Except that "use warnings;"
enables all warning classes, so the current mantra of
use strict;
use warnings;
would always enable them wholesale, unless something changed. Result being
that "We think we're going to deprecate this" predeprecation warnings would
be no different from (as currently implemented) deprecation warnings to
such code (and programmers)
But it's not out of the question to change "use warnings;" to bring in a
"default" set of warnings, instead of "all".
Nicholas Clark
Thread Previous
|
Thread Next