Front page | perl.perl5.porters |
Postings from January 2012
Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)
Thread Previous
|
Thread Next
From:
Abigail
Date:
January 31, 2012 08:30
Subject:
Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)
Message ID:
20120131163018.GE26730@almanda
On Tue, Jan 31, 2012 at 03:06:57PM +0000, Nicholas Clark wrote:
> 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...
Sure, and neither does everyone enable warnings. But that doesn't mean we
cannot optimize for people who do read documentation, and have warnings
enabled.
> > 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;":
I know that. But I think the majority of the code either uses "use warnings;"
or doesn't have warnings enabled at all. The latter group doesn't get warnings,
so they're not relevant here.
I'm looking for ways to ease the pain of people using "use warnings;". IMO,
it's a pain if a next version announces a deprecation, and, at the same
moment, programs start nagging about them, on each and every run.
I understood Yves initial suggestion as "if something is deprecated, don't
warn under 'use warnings'; but require something else (command line option?)".
> $ ./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".
Right. That was my suggestion. "use warnings;" would enable all warnings,
except for "predeprecation". That's something you would have to enable
specifically. Then, using a 2-year cycle as proposed by David, you'd have
something like:
1. "foozles" is scheduled for deprecation.
2. In 5.19 it triggers a "predeprecation" warning. In perl520delta, it's
announced "foozles" will disappear in 5.24. 5.20 code with "use warnings;"
will not warn, so people can upgrade without an immediate hassle.
But they'll have a tool to find the troublesome places (enable the
"predeprecation" category).
3. In 5.21/5.22 the use of "foozles" will trigger the "deprecation" warning,
and it will emit a warning under "use warnings;". This is what is
happening now.
4. In 5.23/5.24, "foozles" will be gone.
Abigail
Thread Previous
|
Thread Next