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

Tom Wyant

In reply to Re^7: Parsing and translating Perl Regexes ( PPIx::Regexp::xplain ppixregexplain.pl _desc.pl ) by Anonymous Monk
in thread Parsing and translating Perl Regexes by LanX

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.