Front page | perl.perl5.porters |
Postings from February 2012
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.
Abigail
Thread Previous
|
Thread Next