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]

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....

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.

Well, I think that may be oversimplifying my position a touch. I do admit that it would be a moot point if it were documented but I think I'd rather see it changed than documented. Well, to clarify, I think that there should be a Regexp module, it should be documented, and the behavior that these thingies retain magic through reblessing should be changed. I can see the usefulness of that behavior but I am not convinced that it outweighs the inconsistency it causes. More on that (but not much more) in a bit.

I regret not being able to discuss this over a beer.

Hear, hear! :-)

The type of dumper I have in mind is more for debugging/development purposes.

By all means then! A debugging tool absolutely should tell you what is really going on regardless of whether what is really going on is documented. You certainly have my... er... "blessing."

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.

Here's the "more on that" that I promised... I think we mostly agree, actually. The product of qr// is a search pattern. I just find it disappointing that it is also a reference which acts differently than other references in a few (admittedly rare) cases. Because of this inconsistency we can't write a module with a constructor that takes any reference and still have the expectation that our stringification will act as a search pattern when the object is used on the right side of the binding operator.

I fully understand that this isn't a huge loss. Aesthetically, it irks me though. Oh well. One man may see a hairy mole where another sees a beauty mark, I guess. Realistically, it is probably of little consequence. I can't even say that I've been bitten by it, but I do imagine there are a few that have been in one way or another.

I've enjoyed this exchange as well, demerphq. Thanks for bringing it up.

-sauoq
"My two cents aren't worth a dime.";

return unless B::svref_2object($r)->MAGIC->TYPE =~/r/;
[download]

The object returned by svref_2object may not have a MAGIC method, so either wrap an eval {} around part of that or check that B::class(B::svref_2object($r)) eq "PVMG".