note tye <p> Thanks for the clarifications. I apologize for my mischaracterization. </p><p> I don't consider the LIMITATIONS section of [cpan://Switch] to be even close to adequate. It mentions rather specific limitations in parsing which is likely to give the opposite impression from the [cpan://Perl6::Rules] disclaimer that I quoted. That is, they imply that other than these few exceptions, the parsing of complex code is unlikely to be a problem. </p><p> But I've seen reports of problems that are not covered by any of the specific cases listed (such as the contents of comment lines causing very random-looking problems). Does the module always correctly distinguish a '/' character for division from a '/' character that starts a regex (which requires tracking prototypes), just to pick one example? </p><p> I once started writing code that would use [cpan://Inline::Files] but quickly switched to a different method when I realized that the module used a source filter. I felt that the problems I'd seen reported for [cpan://Switch] justified a disclaimer like the [cpan://Perl6::Rules] one I quoted and, since neither [cpan://Switch] nor [cpan://Inline::Files] contained anything close to that, I did not feel I could trust [cpan://Inline::Files] at all. </p><p> So, personally, I suggest modifying the documentation of these modules to make the (rather wide, no?) distinction clearer. </p><p> I apologize again for the unfair thrashing. I hope the above helps to explain the misunderstanding that lead to my confusion. </p> <div class="pmsig"><div class="pmsig-22609"><p align="right"> - [tye]<tt> &nbsp; &nbsp; &nbsp; &nbsp;</tt> </p></div></div> 482733 483376