|Don't ask to ask, just ask|
OK, thanks. The object hierarchy may be what it is now, for good or ill.
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
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.
Which of the bugs can I fix without breaking your code?
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" ...
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.
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 :)
Can you be a little clearer on the modifier propagation thing?
Hmmm, I'll try
So I guess its more of a wishlist; 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 xplicit propagation 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 :)