Your argument rests on the premise that this is a bug and not a feature, a postion you come to by there not being a Regexp.pm module, and the lack of documentation of this behaviour. Unfortunately this is from what my research reveals an incorrect conclusion. Somehow I missed a series of mails on P5P (embarrassingly as some of them were CC'd to me directly) that this behaviour is certainly considered to be a feature and that code has been applied to bleadperl (Patch #17813) that does something like what my XS above does. If it has not been done by someone else then I will provide documentation patches to describe the behaviour that Hugo (or Larry) decides is appropriate.

However your position that this is not the best design is probably correct. If REGEX becomes a type, then presumably it would be a ref. Then it could be blessed and isa($foo,'REGEX') would work properly. I doubt that all this will happen though. I beleive the general mentality is that clean implementation arguments should be kept to Perl 6. Major changes like this probably wont happen in perl 5 line. Thats just my impression though.

Anyway. that over, id like to say that im not entirely unsympathetic to your points. I dont think that this reply will do justice to my thoughts on your points. I regret not being able to discuss this over a beer. :-) Anyway here are some points I thought are interesting.

I could also understand leaving it out of Dumper on the basis that references originating from qr//retaining their regexp magic when reblessed is an undocumented and questionable "feature"

The type of dumper I have in mind is more for debugging/development purposes. Whether people should or should not rebless qr//'s is a moot point when you consider that it could happen by accident, and having an easy way to see that it has ("huh, whats that 'bless qr/foo/' doing there!?") just might save some poor soul (like me :-) from pulling whats left of their hair out. For instance Data::Dumper isnt very good with references to scalars, or with aliases, nor with read only values. All three can be the root of bizarreness and having a dumper that is able to display them distinctively is IMO a useful thing.

So, two references both blessed into the same class can act very differently depending only on their origin. Do you see now how that is inconsistent?

I dont agree with your analysis. The product of a qr//, blessed or not, is a search pattern. Theres nothing that says otherwise and much that indicates the contrary. As you keep pointing out this is undocumented behaviour generally speaking. Since nothing says that it ceases to be a search pattern once blessed I see no reason that that intrepretation is any better than its opposite, in fact I tend to lean the other way. Consider that no law in perl says that all members of the same class have to be of the same type. Its an interesting trick that works nicely with trees. Internal nodes are Hashes, leaf nodes are arrays. Things like that.

I'd like to see Regexps elevated to a true Perl type (named REGEX per Larry's recommendation.) I don't think that changing it should be a long process requiring anything but a minimal deprecation period as it is essentially an implementation detail whose public exposure has so far remained undocumented

I agree that the lack of documentation in this area is annoying, and should be corrected, and as I said earlier the implementation doesnt seem the cleanest, but its what we have, and it doesnt look to me from my trawling of P5P archives like its going to change in a big way. Larray suggested the REGEX idea two years ago or so. It never happened, and it doesnt look like its going to happen. In fact theres a bunch of code in the Regexp:: domain (Regexp::Common) Documenting Regexp and providing a baseclass would at least put the issue to rest. Incidentally as I was trawling I came across a quote that I thought was illuminating *grin*

---

|> japhy wrote:
|> :What is the requested/suggested namespace for modules dealing with regular
|> :expressions?
|> 
|> I don't think it is useful to ask that here - the chances of consensus
|> seem vanishingly small.

---

Ideally, it shouldn't be so difficult to do in the first place, right? You shouldbe able to use code like if ref $r eq 'Regexp'or if UNIVERSAL::isa($r, 'Regexp')and the fact that you can'tis a symptom rather than the real problem itself. You've got a work around for the symptom, but the real problem remains.

Looks like there was work done to address these deficiencies in bleadperl. I havent looked into in detail yet. I agree its an issue in 5.6, but a workaround is better than none.

So, you mustknow about an undocumentedfeature in order to understand why qr//->bar;actually works in the above code.

This is true. But I have to admit that I think that the average programmer that didnt know it would try perl -e "print ref qr//;" and see. :-)

perl -MB -le '$r=bless qr//,"P"; print B::svref_2object($r)->MAGIC->TYPE'

Yes I know. I just dont like it. It does basically the same thing as what the XS does, but from a perl side, and it doesnt expose the pattern or modifiers from what I can tell. And reblessing it, extracting the pattern, and unblessing just doesnt seem clean in comparison to the XS. Maybe thats just me. Although I suppose

sub regexp($) {
  my $r=shift;
  return unless B::svref_2object($r)->MAGIC->TYPE =~/r/;
  my $pattern=ref $r eq 'Regexp' ? "$r" : ''.qr/$r/;
  if (wantarray) {
      my $mods;
        $pattern=~s/^\(\?([msix]*)(?:-[msix]+)?:/$mods=$1; ""/e
          or die "Error! $r $pattern";
        chop $pattern;
      return ($pattern,$mods);
  } else {
      return $pattern
  }
}
[download]

does the same thing as the XS. But I think the XS would be a lot faster. :-)

Anyway sauoq this has been a very interesting mail for me. I've learned a bunch in the process. Cheers,

--- demerphq
my friends call me, usually because I'm late....