note
Anonymous Monk
<p><i> OK, thanks. The object hierarchy may be what it is now, for good or ill. </i>
<p> I understand, naming things is hard and its not like I have better ideas, I still have puns (chits) in my code; you saved me so many months of work I'm just surprised you didn't go the extra mile :D I think I'm worth the effort , don't you? :P
<p><i> But to the extent I understand your code it is not only a documentation of PPIx::Regexp bugs, but a neat piece of work in its own right.</i>
<p> :D
<p><i> Which of the bugs can I fix without breaking your code? </i>
<p> Now, I think you can fix all of them without breaking anything :) that is if they are bugs, bugs you'd consider fixing ; I think I tended to use "bug" as euphemism for "now I have to think some more" ...
<p><i> Do I need to reserve some method names for your use? Like xplain()? I'm not sure how to document it, but I'm willing at least to avoid a few that you designate. </i>
<p> Not sure that you actually have to reserve them , but xplain prefix sounds ok
... i'm very unsure about the whole what/should/go/where/oop deal, some would say don't play with other peoples namespace :)
<p><i> Can you be a little clearer on the modifier propagation thing? </i>
<p> Hmmm, I'll try
<br> <b>/(?i)foo/</b> is same as /foo/i, but the "foo" node doesn't know its case insensitive
<br> <b>/foo/aad</b> says semantics are "d" but "aa" and d are mutually exclusive (regexerror++)
<br> <b>/\w/aia</b> says semantics are "a" but "aa" and "a" are different
<p> <b> So I guess its more of a wishlist;</b> I tried to propagate parent modifiers to children using ->modifiers but ->modifiers discarded some information (like errors), so I ended up doing my own exploding :) I also guess the <b>xplicit propagation</b> might not fit with the purpose of tokens, so PPIx::Regexp wasn't doing propagation of modifers, so not much for you to do regarding propagation :)
<p> Thanks
1061170
1061796
1