in reply to Unexpected qr// behavior

Other people said this but in more jargon than was necessary. qr// is a request to compile a regular expression. /s is a modifier to an expression that is to be compiled. Unless you tell the compiler the /s when the expression is being compiled then it doesn't have an effect.

It might be worth having perl throw away the previous compilation work if the current match's flags don't match the expression's flags. It'd then behave somewhat like you expected (except that then you're compiling more often than you thought).

Replies are listed 'Best First'.
Re: Re: Unexpected qr// behavior
by ysth (Canon) on Apr 20, 2004 at 16:13 UTC
    IIRC, Ilya Z has said that qr// compiling immediately instead of at first use is an implementation detail. According to that view, qr// is a request to define a resuable regex, not to compile one.

    And the key part of reusability is having it maintain it's own flags; Regexp::Common would break seriously if the external flags leaked in.

[reply]

      I suppose but the implementation has three cases (in order of best to worst case): re-used as a complete regex, not used at all, re-used as a component of a regex. If that's the motivation I would have thought it would be more important to swap the last two cases so that re-using it as a component isn't worse than not using it at all.

      I'm thinking of /o is dead, long live qr//! for the basis of the sort.

      1. That qr// is compiled once and then used
      2. the qr// is compiled once and then not used
      3. the qr// is compiled twice and used once

[reply]

In Section Seekers of Perl Wisdom