> > 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 

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

Reply via email to