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

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

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Risks in the oblivious use of qr//
by diotalevi (Canon) on Aug 11, 2003 at 18:26 UTC

    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...

        No, it only means that the syntax for a negative /i is (?-i: ... ) and not something hanging off the end of the regex. No additional syntax is needed.