Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Re: Re: Re: Re: Risks in the oblivious use of qr//

by demerphq (Chancellor)
on Aug 11, 2003 at 16:14 UTC ( [id://282917]=note: print w/replies, xml ) Need Help??


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

The only qr// flag that could sanely be overridden is /i and in this case I still call the current behaviour a bug.

Nope. I disagree. If thats a bug then there would be no way to disable /i from inside the regex when the i modifier is used. Which would totally break quite a few regexes that I have. And conversly, would putting a regex compiled with /i into a regex without /i cause the i to cease functioning? Definately not a bug.


---
demerphq

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

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

    I'm taking a positivist approach to this. Where /i is specified it overrides, where it is not, it doesn't. So /$re/i has a local definition of /i but /$re/ doesn't. This implies that where a local redefinition occurs you've gained nothing in performance because the regex fragment must be recompiled to match the local expectations. I think that's just too bad. The alternative viewpoints here might be that the potential performance hit is unacceptable (even given the logical disconnect) or that a a regex fragment is actually a universe unto itself and just because it is included in a larger regex the larger regex's rules shouldn't apply.

    I'm still holding out for a positivist interpretation of this.

      I think you are missing the idea behind this,
      $regex = qr/test/;
      this compiles to (?-xism:test) meaning you are stating that the string test must exist and be lowercase. so ...
      if (/$regex OtherWord/i) {...}
      This seems very logical to me that this should match "test OTHERWORD" but not "TeSt OtherWord" as I have defined $regex to be case sensitive explicitly ! Are you really stating that you feel you need to
      if (/(?-ixsm:$regex) OtherWord/i) { ... }
      to accomplish this case insensitivty on the qr var?? That just blows me away.

      -Waswas

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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://282917]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2024-04-16 04:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found