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:
demerphq
Date:
January 30, 2012 05:22
Subject:
Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)
Message ID:
CANgJU+WkU3h92FrTG7ugg4mHJU1D1ueGO1cwcTujz6GKkCn+AQ@mail.gmail.com
On 30 January 2012 13:50, Abigail <abigail@abigail.be> wrote:
> On Mon, Jan 30, 2012 at 01:02:16PM +0100, demerphq wrote:
>> On 30 January 2012 12:51, David Golden <xdaveg@gmail.com> wrote:
>> > On Mon, Jan 30, 2012 at 5:33 AM, demerphq <demerphq@gmail.com> 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.
Cheers,
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next