My question is this: given an arbitrary blessed scalar ref, how does one efficiently determine if the object is in fact a regex?
OK, I see the "problem" you are trying to solve now. I'm still not sure it is really worth solving though. In fact, your code might do more harm than good if its use became widespread. Why? Because it uses an undocumented "feature" of an undocumented quasi-type to provide functionality of questionable necessity to people writing ill-conceived code.
Regexp thingies are a terrible kludge. They drift about in limbo, being neither entities of a true Perl type nor normal objects. Yes, you can play some tricks with them but that doesn't mean it is a good idea to do so. The fact that the blessed reference returned by qr// keeps its magical regular expression value after being reblessed into another class is probably not a good thing; it may even be a bug. Regardless, it is undocumented and we shouldn't rely on the behavior. (All of which begs the question of whether we should even rely on qr// returning a blessed reference in the first place.)
If Regexp objects are elevated to a real Perl type someday, then code like
my $r = bless qr/foo/, "MyPackage";
probably won't even work and we'll be forced into writing code that is consistent with other types. Instead of getting a reference directly from qr// we'll have to take a reference to whatever it returns and bless that instead. There's no reason not to do that now. Code like
my $r = bless \qr/foo/, "MyPackage";
should continue to work even if Regexps are promoted to a real type. It does require that $$r is used when you want to get at the underlying regular expression but dereferencing isn't that much of an inconvenience, is it?.
The whole mess gets even stickier when you consider that strings can be used in much the same way that precompiled regexes are.
$ perl -le 'my $r = "bar"; print "yes" if "foobarbaz" =~ $r'
yes
Now, keep that in mind as you reconsider the issue of whether Regexp thingies should maintain their magic after being reblessed into another class. It can lead to inconsistent behavior. For instance:
#!/usr/bin/perl -w
use strict;
package P;
use overload '""' => sub { 'stringified' };
package main;
local $\ = "\n";
my $regex = qr/match/;
bless $regex, 'P';
my $plain = \my $t;
bless $plain, 'P';
print '"stringified" matched $regex' if "stringified" =~ $regex;
print '"stringified" matched $plain' if "stringified" =~ $plain;
__END__
"stringified" matched $plain
So, because of Regexps, not all references are created equal. Bummer.
Yet another inconsistency due to the Regexp quasi-pseudo-sorta class is that you can write your own Regexp package and the things returned by qr// get access to your methods.
#!/usr/bin/perl -w
use strict;
package Regexp;
sub new { my $r; bless \$r }
sub f { q("I'm a Regexp.") }
package main;
local $\ = "\n";
my $qr = qr/foo/;
my $ob = Regexp->new();
print '$qr says, ', $qr->f;
print '$ob says, ', $ob->f;
print '$qr isa Regexp' if $qr->isa('Regexp');
print '$ob isa Regexp' if $ob->isa('Regexp');
print '$qr: ', $qr;
print '$ob: ', $ob;
__END__
$qr says, "I'm a Regexp."
$ob says, "I'm a Regexp."
$qr isa Regexp
$ob isa Regexp
$qr: (?-xism:foo)
$ob: Regexp=SCALAR(0x805f148)
That's not very nice behavior given that it isn't, AFAIK, documented that you shouldn't write a Regexp package of your own.
All of this leads me to the conclusion that, if someone actually finds your XS code useful, they are almost certainly doing things that they ought not be doing anyway. ;-)
-sauoq
"My two cents aren't worth a dime.";
|