> > The solution is simple, you know, Mark. Why not just write up your own > > alternate S26, redesigning Pod 6 the way you think it should work, and > > then publish your proposal for consideration here? > > Couldn't most of this be figured out by making Pod6 extensible (or > whatever the right term is). Pod6 would be more of the syntax and basic > operation, but other people could have custom directives that their > Pod6 translators and formatters could then use. That is, not all of > this has to be in the spec if the spec has a way to make it possible > later. :) > > And, as far as writing a new S26, does this mean that this really isn't > open to discussion? That is, if we want something different than you > want we have to have competing specs and there won't be any compromise?
My feeling on the matter is that both camps are right. I think that Damian is right that Pod6 should be completely independent. I think that Mark is right that we need a consistent way to output OO descriptions in pod. I think the problem is that we currently have the "perldoc" program which would probably be better named as poddoc or simply pod. I think perldoc is currently a bad and misleading name for the Plain Old Documentation generator. I think that perldoc should be the magic tool that does pod extraction (ala poddoc) and ALSO does some version of Mark's autoextraction of inlined documentation. @Larry hasn't said anything about having inlined/introspectable documentation. I think that it would be nice to have something standard and I think that Mark's proposal is pretty nice. The "real" perldoc program can have full access to the code. This is actually a downside as well - if the code doesn't compile, then perldoc would not be able to generate the code - but it could always show an error that the code doesn't compile and then show what poddoc would show. The outcome is that poddoc can be Pod6 "pure" and perldoc can be (as its name suggests) documentation for Perl. Just my opinions. Paul Seamons
