Russ Allbery wrote:
>
> > - moving $self->cmd_foo() dispatch to Pod::Parser,
> > - allows =for/=begin...=end filtering
that second bullet was under the "creating a Pod::StdParser" item
in my original, so....
> This is certainly doable (although I question whether Pod::Parser is the
> right place for it), but it's also worth bearing in mind that you're
> talking about a grand total of about twenty lines of code here, tops.
> Very stable code, too. There's something to be said for each translator
> just doing this very small amount of work itself so that it has control
> over it.
...I wasn't proposing putting =for/=begin...=end processing in Pod::Parser,
but in Pod::StdParser. Not sure if you were clear on that, but other
readers of your reply might be confused by it.
>
> > - creating a Pod::StdParser that
> > - knows about well-formedness,
>
> What well-formedness in particular are you thinking of? This is a serious
> question; in working with translators, I've found that this isn't nearly
> as large of a problem as one might think. There really isn't much about
> POD that *can* be ill-formed. Notice that there are precisely four carps
> in the entirety of Pod::Text (unrecognized interior sequence, unrecognized
> E<> escape, =back without =over, and =item without a tag).
That's them. I agree no big deal. By the time you factor those out, and
add some "standard" utility (as above & below), Pod::StdParser becomes a nice,
easy base class to use for parsing, well, *standard* PODs :-).
> > - implements C<=also>, and
>
> See other comments.
>
> > - provides some status attributes & methods to allow context to be
> > queried, like if you're in an =for/=begin...=end region
>
> I just use instance variables for this in my translators, and that works
> fine. Again, this is a very small amount of code.
>
> > - porting Pod::Text, some Pod::Html, etc., to use Pod::StdParser would
> > be good.
>
> So far, I've honestly not seen any reason at all to do this.
Just to get the C<=also> functionality (or whatever syntax), and for the
sake of factoring out common code (which I would never bother to do
if it weren't for doing the C<=also> stuff in the first place. "If it ain't
broke...").
>
> > Subclasses to support added commands would be able to define new members
> > for each command they add: =bar needs a sub cmd_bar() {}.
>
> Again, very little code needed for this.
A little here, a little there, and pretty soon you're talking real mone^H^H^H^Hcode.
:-).
That said, it's not worth factoring working code just for the sake of factoring.
And I don't see many new POD->Foo xlators coming down the pike. And I
just want example -> test suite extraction. I *hate* having broken examples :-).
> I am interested in continuting to maintain the POD translators that I
> wrote, and if this is the way that we want the wind to shift, I'll try to
> help. But so far, again, I'm unenthused.
- Barrie
