Steve Grazzini wrote:
> On Mon, Jul 21, 2003 at 04:40:19PM -0400, Jeff 'japhy' Pinyan wrote:
> > On Jul 21, Jeff 'japhy' Pinyan said:
> >
> > > This is the issue. Why are the $DIGIT variables bound to the
> > > block they're in IN TOTALITY, rather than for the life of the
> > > execution of the block?
> ...
> You're explaining this much more clearly than I had done, but let me
> jump in again --
>
> The magic regex variables *themselves* live forever and don't obey
> any scoping rules. They don't have to worry about scope, since as
> you said, they don't contain any data. Their values are fetched
> dynamically by looking at the "last match" (which is what I've been
> calling PL_curpm, which is the dynamically scoped PMOP pointer).
>
> PL_curpm behaves consistently, although the way it's dynamically
> scoped is slightly unusual, as you said.
>
> But the PMOP doesn't contain any data *either*. It has a pointer
> to REGEXP structure, which contains, among other things, the compiled
> pattern and what I'll call the "match data". The match data might
> include a copy of the target string and offsets for each pair of
> capturing parens, and it can be used to calculate the value of $1
> or @- (or a host of other variables) dynamically.
>
> The problem with this set-up is that PL_curpm is dynamically
> scoped, but the REGEXP, which contains the data we're interested in,
> isn't.
Aha! (slaps forehead, finally understanding)
>
> Tying the match data to the compiled pattern (and thence to the
> PMOP, for pity's sake) is, arguably, bad design...
>
> You can also see it misbehaving here:
>
> my $rx = qr/(...)/; # REGEXP 1
>
> "foo" =~ /$rx/; # PMOP 1 / REGEXP 1
> { "bar" =~ /$rx/; } # PMOP 2 / REGEXP 1
>
> print $1; # "bar"
>
> In this one there are two distinct PMOPs (the m// operations) but
> only one REGEXP, which is what we've stored in $rx.
>
> When we print $1 the chain of references looks something like
>
> $1 -> PL_curpm -> <PMOP #1> -> $rx -> <match data>
>
> [ Really the PMOP points directly to the REGEXP inside $rx. ]
>
> And the match data inside $rx comes from the time it matched "bar",
> since there's no mechanism for saving and restoring that kind of
> thing.
>
> Anyway, apologies for the blood and perlguts --
Steve and Jeff, thanks for the explanations. Obviously, I underestimated the
complexity of the underlying issues :~)
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
