==
> I lie: the other reason qr{} currently doesn't behave like that is
that
> when we interpolate a compiled regexp into a context that requires
it be
> recompiled,
Interpolated qr() items shouldn't be recompiled anyway. They s
On Sun 24 Sep, Hugo wrote:
> In <[EMAIL PROTECTED]>, Richard Proctor
> writes
> :
> :TomCs perl storm has:
> :
> :> Figure out way to do
> :>
> :> /$e1 $e2/
> :>
> :> safely, where $e1 might have '(foo) \1' in it.
> :> and $e2 might have '(bar) \1' in it. Those won't work.
> :
> :If e1 a
> I lie: the other reason qr{} currently doesn't behave like that is that
> when we interpolate a compiled regexp into a context that requires it be
> recompiled,
Interpolated qr() items shouldn't be recompiled anyway. They should
be treated as subroutine calls. Unfortunately, this requires a
In <[EMAIL PROTECTED]>, Richard Proctor writes
:
:TomCs perl storm has:
:
:> Figure out way to do
:>
:> /$e1 $e2/
:>
:> safely, where $e1 might have '(foo) \1' in it.
:> and $e2 might have '(bar) \1' in it. Those won't work.
:
:If e1 and e2 are qr// type things the answer might be to loca
TomCs perl storm has:
> Figure out way to do
>
> /$e1 $e2/
>
> safely, where $e1 might have '(foo) \1' in it.
> and $e2 might have '(bar) \1' in it. Those won't work.
If e1 and e2 are qr// type things the answer might be to localise
the backref numbers in each qr// expression.
If th
