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