in reply to Re: Re: Re: Re: Re: Re: Re: Risks in the oblivious use of qr//
in thread Risks in the oblivious use of qr//

That is exactly what I'm saying. The fact that a qr// regex stringifies with a (?-xism:$re) wrapper doesn't mean to me that it is actually core to it. The regex itself is hard coded into some nodes which actually indicate which of 'ism' apply and its that that you're saying should remain static and I'm saying should bend. Now please keep in mind that I've moderated my stance a bit and I only think /i is acceptable to have this behaviour for. The other three flags 'x', 's' and 'm' have more significant meaning and I can't bring myself to think of a situation where it would make sense to override any of those.

So really, what I'm saying is that if you had previously said $test = qr/test/ and later said /$test FOO!/i that the /i-ness of the $test object would be overridden and that if you wanted to keep that you'd have to said /(?i:$test) FOO!/i. I had originally written $test = "test" then all of this would behave exactly as I'm suggesting. (except that 'xms' wouldn't be specified either).

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re: Re: Re: Risks in the oblivious use of qr//
by waswas-fng (Curate) on Aug 11, 2003 at 18:06 UTC
    I see what you are saying. But I disagree, with  $test = "test; you are not explicitly stating any regex options whereas  $test = /test/; you are (explicitly stating case sensitive by leaving out the /i). I say take the most detail which would make $test's regex flags higher precedence -- they are more detailed. Lose that efect and you lose a level of detail on the regex. What gain can you see in disregarding how you define a regex's flags earlier in a program? I can see plenty where you would want the regex to act as _YOU_ defined it in the most detail. I guess we are just going to butt heads on this one =)

    -Waswas

      The core difference is that I don't see /test/ as having an explicit absense so much as I see a 'default' going on. Its just not explicit. With /test/i I see an explicit marking on what behaviour to use. I just don't think "explicitly not there" is a good way to think about it. If I meant to be explicitly off then I'd have written (?-i:...).

      Of course I don't actually write that way, that's just how it *should* work.

        This implies that the flag that holds the /i status has to be tristate and not bi state. It also means that a new modifier needs to be added.

        Personally I think this is probably not worth the time as its trivial to use a regex to prep a qr// so that it is /i insensitive.


        ---
        demerphq

        <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...