Front page | perl.perl5.porters |
Postings from February 2012
Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)
Thread Previous
|
Thread Next
From:
demerphq
Date:
February 1, 2012 03:55
Subject:
Re: How we deprecate (was Re: Deprecating '\w {' in v5.16)
Message ID:
CANgJU+Vk7YKzT0+cnP=_Xext10ZXfHOTTLKvtvfP0igyuOWq5w@mail.gmail.com
On 1 February 2012 12:17, Abigail <abigail@abigail.be> wrote:
> On Wed, Feb 01, 2012 at 11:03:05AM +0000, Nicholas Clark wrote:
>> On Mon, Jan 30, 2012 at 11:20:10AM +0100, Abigail wrote:
>> > On Mon, Jan 30, 2012 at 07:51:41AM +0100, Steffen Mueller wrote:
>> > > On 01/30/2012 03:21 AM, David Golden wrote:
>> > >> Jesse's vision included the notion that changes should happen
>> > >> lexically under in a declared version block, whenever possible. So in
>> > >> this case, perhaps the deprecation warning should only occur under
>> > >> "use v5.16"? Frankly, I think the lexical version declarations are
>> > >> going to be horribly confusing and I question whether that's the right
>> > >> path forward or whether a simpler policy change would be more
>> > >> user-friendly.
>> > >
>> > > It seems to me like deprecation warnings should be lexical in a "use
>> > > 5.future" enabled block IF the deprecated feature is only removed in
>> > > "explicit 5.future enabled" code and continues to be supported
>> > > indefinitely in older versions (whether explicit or implicit).
>> > > Otherwise, we may as well remove the deprecated feature (after
>> > > deprecation) entirely as barely anybody can tolerate deprecation
>> > > warnings.
>> >
>> >
>> > Right. But if it's going to be removed only with some feature enabled,
>> > a new meaning will also only occur with said feature enabled.
>> >
>> > Which means that if a subroutine is documented as "takes a pattern as
>> > first argument", I would not be able to pass it '\w{foo}', as its meaning
>> > will be different depending on whether the sub uses the pattern with
>> > said feature enabled or without.
>> >
>> > Which seems like a bad idea to me.
>>
>> That's a good point which I'd not thought of. Because patterns weren't
>> first-class (and sort of still aren't quite), it's normal to pass them as
>> strings. Whilst we could annotate regular expression *objects* with
>> metadata about the lexical context of their compilation, we can't with
>> strings.
>>
>> Which makes it "really hard" to sanely try to support more than one
>> variation of regular expression syntax in the same interpreter.
>
>
> Note that regular expression objects come with their own can of worms,
> as qr objects often go through a stringify-compile cycle. Just imagine
> this:
>
> my $qr1 = do {use 5.18; qr/PATTERN1/};
> my $qr2 = do {use 5.20; qr/PATTERN2/};
>
> sub foo {
> use 5.16;
> my $pattern = shift;
> ... do something with $pattern ...
> };
>
> use 5.22;
> foo ("$qr1$qr2");
>
> It basically means that even your regexp objects are tagged with meta-data
> about their lexical context of compilation, you'd have to be able to stringify
> them in such a way that it their meaning is version independent.
I view string regex concatenation to be a convenience. If it breaks
things subtly as a side effect that is the users problem.
The proper way to concatenate regexes is inside of a pattern, or a qr//.
You and I have discussed why you prefer "" concatenation and I
understand the practical issues, but I think your solution is a work
around for the deeper problem, which Dave M is working on improving,
and which I hope will be ultimately solved.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next