develooper Front page | perl.perl5.porters | Postings from August 2010

Re: qr stringification: why are xism always present? I'm worriedabout backward compatibility

Thread Previous | Thread Next
From:
Ben Morrow
Date:
August 1, 2010 12:02
Subject:
Re: qr stringification: why are xism always present? I'm worriedabout backward compatibility
Message ID:
20100801190240.GA69917@osiris.mauzo.dyndns.org
Quoth public@khwilliamson.com (karl williamson):
> 
> The reason is that the code always outputs the modifier, even for the 
> the existing semantics, so the stringification is permanently different 
> from before.  That got me to thinking that it should be possible to omit 
> the modifier from the stringification unless it is different from the 
> default.  Thus backward compatibility would not be broken, although it 
> is a dangerous thing for modules to be relying on knowing all the 
> possible modifiers, and someone could pass them a regex compiled with a 
> new modifier that they don't know how to deal with, not just these, but 
> any new ones.
> 
> But there must be some reason that xism are always shown in the 
> stringification, whether they are in effect or not in effect.  But I 
> can't think what it might be.  It would have been simpler for the 
> original design to only output them in the stringification when 
> different from the default.  So there must be a reason why the plus or 
> minus of them is always output.  Does that reason apply to these new 
> modifiers?

The reason is so that interpolation under different flags works
properly. Currently, if I have

    my $rx = qr/f./s;

is stringifies to (?s-xim:f.), which means that when I interpolate it
into a pattern with different flags

    "AFx" =~ /a$rx/i;

the /i is 'cancelled' for the duration of the interpolation (and /s
activated). If it were changed to stringify to (?s:f.) only, the match
above would change from failing to passing.

So yes, this applies to your new modifiers as well. Every stringified
qr// should include a Cx flag of some kind. The only sane alternative
would be to break compat once, now, by changing the stringification to
something like (?~s:f.), using a new pattern which guarantees to set all
non-specified flags to the default for the duration of the group rather
than leaving them as they were outside. This would allow adding more
flags in the future without breaking compat more than is strictly
necessary.

Ben


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About