to fix what you consider a bug.Did I mention anywhere there's a bug?
I'm just stating what is happening. That the trick the OP quotes only works because POD parsers are stupid, and don't look at context.
nobody will ever dare to deprecate what you consider to be wrong.Again, you seem to make up words and ideas out of thin air.
Another example of a "misuse" effectively becoming standard is the tolerance regarding empty lines surrounding =statements. Nobody will ever be able to enforce the original rules here so we have to accept the new standard.What "tolerance"? Note that Perl doesn't require empty lines; it's the POD parsers that do. That fact is even mentioned in perlsyn:
Note that pod translators should look at only paragraphs beginning with
a pod directive (it makes parsing easier), whereas the compiler
actually knows to look for pod escapes even in the middle of a
paragraph. This means that the following secret stuff will be ignored
by both the compiler and the translators.
$a=3;
=secret stuff
warn "Neither POD nor CODE!?"
=cut back
print "got $a\n";
You probably shouldn’t rely upon the "warn()" being podded out forever.
Not all pod translators are well-behaved in this regard, and perhaps
the compiler will become pickier.
Hmm, that last sentence seem to be at odds with your so we have to accept the new standard..
The possibility to have "dual" code evaluated by both parsers is a genius possibility to produce documentation in a DRY way, most people won't ever want to miss again.I'd think most people in this case will prefer KISS over DRY. I certainly hope so.
In reply to Re^11: POD Meditation?
by JavaFan
in thread POD Meditation?
by temporal
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |