Front page | perl.perl5.porters |
Postings from January 2012
On 25 January 2012 18:20, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> * demerphq <demerphq@gmail.com> [2012-01-25T11:44:53]
>> no overloading;
>> my $qr1=qr/(foo)/;
>> my $qr2=qr/(boo)/;
>> my $qr3=qr/(loo)/;
>> ok( (("foo" =~ $qr1) && $1 && ($1 eq "foo")), "Raw regex");
>> ok( (("boo" =~ /$qr2/) && $1 && ($1 eq "boo")), "Raw regex redux");
>> ok( (("xlooy"=~/x${qr3}y/) && $1 && ($1 eq "loo")),"Embedded regex");
>> ok("$qr1"=~/REGEXP/,"Sanity check");
>
> What do you think about the suggestion that embedding a regexp object in
> another regexp under "no overloading" is like doing almost anything with ($x =
> undef) under "use undef::stringification"?
If we go that way then the first two tests should fail too.
I mean, it is only an accident of implementation that regexes use
stringification to handle embedding. Dave M I believe has done and may
have work in progress to fix it so that it is done properly. Larry has
talked of dealing with this properly. If we did handle it properly we
could embed patterns that use totally different regex engines inside
each other, etc.
Think about it, does "no overloading" stop an array being an array?
Does it stop a hash being a hash? Yet we want it to essentially make
regex patterns stop being regex patterns. I dont think that makes
sense.
Consider the subtler implications of this. For instance observe here:
$ ./perl -Ilib -E'$qr=qr/(foo)/; $_="xfoo"; say /x$qr/ ? $1 : "no"; no
overloading; say /x$qr/ ? $1 : "no"; $qr2=qr/(oo)/; say /xf(??{ $qr2
})/ ? "yes: $1" : "no" '
foo
no
yes:
Note the last result. It matches inside of a (??{ ... }) and but does
not capture.
I personally think that side effect aside (such as capturing) that:
/x$qr/ and /x(??{ $qr })/
should be the same. The docs practically demand it. I would say that
this patch muddies already disturbingly muddy water, and needs to be
thought through more.
So IMO I suggest pretty strongly that this patch be reverted or at
minimum fixed so it doesnt change the behavior of REGEXP objects
inside of a match. Especially given there are related doors we have
long wanted to keep open and eventually travel down.
Note, I dont have a problem with this changing _stringification_
behaviour. But I dont think it changing embedded regexes is a good
idea, I dont consider that the same as stringification.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next