On 1 August 2010 21:44, karl williamson <public@khwilliamson.com> wrote: > Ben Morrow wrote: >> >> 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. > > 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. Because it would break /(?i:foo(?s:[0-9a-f].*))/ Also there is a pesky form like this: /(?i)foo(?s)[0-9a-f]/ This behaviour must not be changed. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next