Brad Appleton wrote:
>
> On Wed, Aug 02, 2000 at 03:52:15PM -0400, Barrie Slaymaker wrote:
> > =head1 IMPLEMENTATION
> >
> > The C<=also> command is implemented in Pod::Parser in a process
> > called "=also mangling".
>
> Why is this handled in Pod::Parser when =for and =begin/=end
> aren't presently handled or known to Pod::Parser??
The reason I'm proposing putting it in Pod::Parser is backwards
compatibility; to prevent breaking code that currently uses
Pod::Parser. Otherwise, current Pod::Parser based utils will
whine, and possibly break, when they encounter C<=also>.
C<=also for|begin|end> are similar to C<=cut> in that they affect
the flow of parsing: they simulate having duplicate POD content,
one "normal" copy, and one copy constrained by =for or =begin..=end.
The following two sequences would be equivalent:
--------8<-----------8<------------
=item foo
bar
boo
bah
=for test foo.t
bar
boo
bah
blah blah blah
=cut
--------8<-----------8<------------
=item foo
=also for test foo.t
bar
boo
bah
blah blah blah
=cut
--------8<-----------8<------------
> I'd rather see this implemented as something in Pod:::ParseUtils
> that all other POD xlators can use, rather than inside Pod::Parser
> where it would break existing code/scripts (even if those aren't
> part of the core Perl distribution).
It is specifically put in Pod::Parser in order to *not* break existing
code/scripts (unless they already use C<=also>, though I've never heard
of any).
If we decide that it's Ok to mandate changes to the most common
Pod::Parser based POD processors, I certainly don't mind providing
some subclass of Pod::Parser or some other utility in Pod::ParseUtils.
- Barrie
