Front page | perl.perl5.porters |
Postings from January 2012
On 30 January 2012 14:22, demerphq <demerphq@gmail.com> 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