Moritz wrote:
> However it seems we have to pay a price: each act of rendering a Pod
> file actually means executing the program that's being documented (at
> least the BEGIN blocks and other stuff that happens at compile time),
> with all the security risks implied. So we'll need a *very* good
> sandbox. Is that worth it?
I believe so. The sheer range of approaches that people said they wanted
Pod to support made it impossible for Pod to support anyone, unless
everyone can configure Pod directly. The choice then becomes: do we
provide Pod with a DSL for configuration, or do we just use
Perl 6 as its metalanguage? The answer seemed pretty obvious then.
I'm certainly not smart enough to design a config language that's powerful
enough to do everything everyone wants documentation-wise. But Larry is.
And already did. ;-)
Sure, there are downsides: Pod becomes much more tightly tied to Perl 6.
And the black hats can indeed do bad things with it.
But, you know, the bad guys have been able to do that with CPAN modules
for a long time now, and the incidence of that happening is vanishingly
small. I'm prepared to bet that most people who download something from
CPAN don't scour the source checking for system('rm -rf /')'s, nor do
they run that code in a sandbox.
And the people who *do* take such precautions will simply start to do
the same thing for any documented code (or coded documentation :-). Or
maybe the sandbox will just be an option to disable any DOC blocks
except the default one. Or else maybe perl -doc will just run under an
augmented taint mode that suspects not just anything that emerges from
an input op, but also anything created in a DOC'd command.
> Two minor comments:
>
> A valid identifier is a sequence of alphanumerics and/or
> underscores, beginning with an alphabetic or underscore
> >
>
> Is there a good reason to deviate from Perl 6's definition of an
> identifier? For the sake of consistentcy I'd just say that the Perl 6 rules
> apply.
Great idea. Should definitely be that way. Patch applied.
> sub fu ( #= This text stored in C<&fu.WHY>
>
> This seems to be ignorant of multi subs.
Not ignorant of. Just not an example of. ;-)
> If I write
>
> multi sub fu () { #= some Pod
>
> Then &fu is a multi, not a particular candidate. Does it actually
> attach to the .WHY of the candidate? Or of the multi?
Of the particular candidate. I'll make that clearer.
(If you want to document the entire multi, attach the documentation to
the proto.)
Damian
