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> </tt>
</p></div></div>
482733
483376