Thanks for the clarification.

It was the intent that the actual modifiers in effect be propagated so that you actually know what is in effect at any point in the Regex. Whether I did it right is another question. Or whether I did it in an obscure way and then didn't document worth a hoot. At any rate, I think the knowledge that the token for the "f" in /(?i)foo/ is not case-sensitive should be available somewhere.

On the other hand, I am not sure how seriously I am going to take /foo/aad, since it does not compile (at least under 5.18.1). On the gripping hand, there are already representations of invalid code, so maybe the "d" could become an invalid token. The disgusting thing is that it looks like I actually programmed semantics for this case, and that's definitely wrong.

As for munging around with other peoples' name spaces, I believe it is generally frowned upon. But I have also done it when desperate. It appears you have a genuine need to attach extra functionality to the PPIx::Regex classes. And the strict O-O way requires you to subclass all however-many-there-are of them, and you STILL have to go through and rebless everything the parser spits out -- or I have to figure out how to make it use your classes as an option. The fact of the matter is that Perl does Aspect-Oriented programming right out of the box, so we may as well recognize the fact.

What I'm currently thinking about is reserving to myself all subroutine names that begin with ASCII a-w, plus all that begin with one or two underscores, plus all the all-uppercase ones like DESTROY (which I actually use), AUTOLOAD (which I don't (yet)) and so on. Anything else would be fair game. If you plan to release your code as a CPAN module, I might need to document what parts of the name space you are using (and therefore break your anonymity to some hopefully-minimal extent), in case someone else wants to try the same thing.

Yes, I thought about having PPIx::Regexp actually explain what the tokens were, but I had no pressing need. The problem I was trying to solve was that I was helping out with Perl::Critic, and they were using a different regex parser, which was weird, unmaintained, and started throwing warnings about Perl 5.12 (or maybe 5.14).