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
karl williamson
August 1, 2010 12:45
Re: qr stringification: why are xism always present? I'm worriedabout backward compatibility
Message ID:
Ben Morrow wrote:
> Quoth (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.

I still don't understand.  I had considered interpolation, and it still 
seems to me that the absence of a modifier means use the underlying 
default for the duration of that interpolation, no matter what the outer 
regex says.  I don't see a flaw in that thinking.

> Ben

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About