in reply to Re (tilly) 1: Finally, a $& compromise!
in thread Finally, a $& compromise!

As already mentioned, $` and $' are controlled by the same flag and so the pragma already affects them as well.

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re (tilly) 3: Finally, a $& compromise!
by tilly (Archbishop) on Nov 28, 2001 at 21:06 UTC
    As specifically pointed out in the section Capturing still works, the use of $1 and friends turns support for them back on, despite the pragma.

    I did read what japhy wrote before I posted. While it is nice to turn off the production of capturing strings, the main time I do enough matching that I really care about capturing or not is tokenizing, when I am almost definitely going to be using capturing matches. So this module helps with the problem, but not in the only case where I care.

      "sawampersand" is a single bool. I can't come up with any reason that this code would need to have "sawampersand" be treated as "true" when capturing is being done. I think either japhy was not being completely clear when he wrote that paragraph or he misunderstood some subtleties about how $& and capturing interact.

      Sorry you felt that I was accusing you of not reading.

              - tye (but my friends call me "Tye")
        japhy explains the connection better in Re: Re: Finally, a $& compromise!.

        If I understand what he is doing correctly, he is only playing games with deciding whether or not to capture. If you capture, the decision of whether or not to capture $` and $' is separate.

        I would like the pragma to be able to decide not just whether or not to capture, but whether or not to copy the whole string. $`/$' are already distinguished from $& in Perl, and separate control would be nice here.

        UPDATE
        As just discussed in chatter. Using $& is documented in perlre (as of 5.005 and later) as not being as bad as $` and $'. But in my simple test above, it produced the same slowdown. Which indicates a mistake in the documentation...