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 30, 2012 05:22
Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)
Message ID:
On 30 January 2012 13:50, Abigail <> wrote:
> On Mon, Jan 30, 2012 at 01:02:16PM +0100, demerphq wrote:
>> On 30 January 2012 12:51, David Golden <> wrote:
>> > On Mon, Jan 30, 2012 at 5:33 AM, demerphq <> wrote:
>> >> I personally think that deprecation warnings would be a lot easier to
>> >> add, and a lot less painful,  if they were warn-first-use, instead of
>> >> the normal warn-every-use.
>> >
>> >    use less 'warnings';  # :-)
>> >
>> > Serious note -- this seems like it should be a user option, not a
>> > default, if implemented.  Are we out of command-line flags?  (Would -X
>> > already suffice for this?)  I note that "-q" (quiet) is available.
>> I dont think it should be a user option. I think it should be the
>> default behavior for deprecation warnings. It does not add value to
>> repeatedly tell someone that the code is deprecated every time they
>> use a deprecated feature. After all the code is NOT misbehaving, it
>> simply will no longer work in a later release. This is quite different
>> from telling them that their code might be silently doing something
>> different than they think, which is why we normally warn every use.
> IMO, depraction warnings belong in linters. "use warnings" isn't a linter.
> I think that, for those that have warnings enabled, the emitting of warnings
> on each and every run of the program will be considered as bad as a breakage.

I just hope that people agree that it warning once per line using a
deprecated feature, and not once per invocation of that feature is the
lessor of two evils.

> What's the message we want to pass to the user? "Hey, your code is fine now,
> so you don't have to do anything now, but if in the future you're going to
> upgrade your perl, it may no longer work. However, although you don't have
> to fix this now, I'll keep bugging you until you do". To me, that's as useful
> and annoying as a car that starts beeping when the fuel tank drops below 99%,
> warning you that you don't have to refuel now, but eventually, you need to,
> and it will keep reminding you about it.

I agree mostly. But I think this a balance issue. We have multiple
priorities, and whatever mechanism we choose needs to satisfy as many
of those priorities as possible.

I think we need to:

a) inform the user that their script will break in a future release of Perl.
b) do so in a way that ensures a high level of compliance
c) do so in a way that ensures a low of level of negative consequences
for the user.
d) do so in a way that is cost-effective from the point of view of
developer investment.

I personally think that our current strategy satisfies a, b, and d,
but does not at all, in any way, satisfy c.

I believe my proposal satisfies c without jeopardizing a b or d.

So as long as we don't have an alternative strategy then I believe
that what I proposed is a reasonable middle ground.


perl -Mre=debug -e "/just|another|perl|hacker/"

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