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
Rafael Garcia-Suarez
January 30, 2012 05:33
Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)
Message ID:
On 30 January 2012 14:22, demerphq <> wrote:
>> 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.

I think most deprecation warnings are compile-time, so they'll warn
once already.
This is not the case for at least :
- "goto" to jump into a construct (runtime warning)
- Use of *glob{FILEHANDLE} is deprecated (runtime warning)
- chdir('') or chdir(undef) as chdir() (runtime warning, should be
easy enough to move into a ck function)
- Use of inherited AUTOLOAD for non-method %s::%s() is deprecated
(runtime warning)

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

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