John Porter asked:
> Michael Mathews wrote:
> > This ... underlines why POD is not a good way to comment code. ...
> > This RFC would seem to address the issue quite neatly.
> So, are you saying that if this RFC is implemented, POD would be
> a good way to comment code?
I do consider this a potential alternative to the MLC RFC but to my mind it
addresses the opposite problem: how to get executable code into a commenmt,
rather than how to get executable code out of the program (which is the
specific usage many proposed solutions seem to snag on).
Examples:
a) Jane wants to keep some chunk of code in the file (for now) but doesn't
want it to execute and doesn't want it to show up in the documentation --
this won't help her.
b) Jack wants to nest a block of comments, actually to quickly disable a
large swath of code without regard for any potential block comments
within -- this won't help him (since "=cut" ends all POD, not just the most
recent item).
To be fair, neither of these are examples of using a comment function for
"comments" though, but rather using a comment function to disable sections
of code and I suppose that makes as much sense as using POD to disable code.
I think, however if we wanted to support this type of misuse two more
features would be needed:
aa) Allow a POD that is "private", and won't ever show up in the
documentation:
=private
took this next part out because the client insisted, though I predict
they will flip-flop
...lots of disabled code...
=cut
bb) Allow for nesting
=private
...lots of disabled code...
=POD
...lots of POD...
=cut
...more disabled code...
=cut
