develooper Front page | perl.perl5.porters | Postings from January 2012

Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)

Thread Previous | Thread Next
January 31, 2012 08:30
Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)
Message ID:
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
> > > <> 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 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

> > 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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About