Mark Overmeer wrote:
Then, when you want to add some docs to the method, to help the
correct use, add it, for instance like:
method isValidPostalCode(str $postalcode) returns bool {...}
` Check wether the postal code confirms to the standards
`$postalcode: a string with blanks trimmed.
`return: the string is not cleaned-up.
or maybe (exact syntax open to discussion)
method isValidPostalCode(str $postalcode) returns bool {...}
#= Check wether the postal code confirms to the standards
#=$postalcode
#= a string with blanks trimmed.
#=return
#= the string is not cleaned-up.
Would the following syntax suffice?
method isValidPostalCode(str $postalcode) returns bool {...}
=PURPOSE Check weather the postal code confirms to the standards
=ARG $postalcode
a string with blanks trimmed.
=RETURN
the string is not cleaned-up.
Because you can already do precisely that in the current design of Pod 6.
And having done it, the current Pod::Parser will extract all of that
information (including the source code), preserving the sequential and
hierarchical relationships, and present you with an internal object
representation that your documentation tool can then analyze and
convert to whatever content and layout you prefer (including
non-semantic Pod that you can then feed into any of a dozen
back-ends).
Damian
