Ah, but at least in most of those cases the programmer would still have to write something to describe the data you are pulling out: The bare data itself isn't all that useful. (What does it mean?)

Whereas the inheritance and dependencies are useful even (or especially) when simply listed. So at least there's a reason for drawing a line there. ;)

True, but you might be able to get *something* from the variable names. e.g.

sub foo {
   my ($needle, @haystack) = @_;

   ...
}
[download]

Having those available might be useful (of course you can read the source as well, but you might want to see that from a different module).

Might. It's on the slope of diminishing returns, though. (And the numbers of different ways to get variables out of the arg array is huge.)

Parent classes and dependencies are machine-document able, fairly easily. They are conceptually similar. And documenting them for a human is usually copy-paste-format in my experience. Trying to automatically document functions may be useful, but it wouldn't be something I'd want to run with the dependency tree. (Which I would want to run on every module I've ever written: It'd make my life simpler.) Functions I'd rather do by hand, usually.

(I guess I'm looking at this as a way to document my code, not code someone else has written that I want to use.)

This is exactly the sort of specificity that a plugin would grab. Macropod::Parser::Include::signatures would be loaded by Macropod::Parser::Include plugin , and passed the in play ppi statement which might be use signatures along with the whole PPI source document and the in play Macropod::Document. Hopefully being pluggable in this way permits someone with specialist interest to handle just their special cases.


I can't believe it's not psellchecked