in reply to Offtopic: POD directives
in thread Question on reference

No you don't.

Not if you are only using them as a convenient form of multi line comment. I seriously doubt that anyone is going to run perldoc on this snippet.


Nah! Your thinking of Simon Templar, originally played by Roger Moore and later by Ian Ogilvy

Replies are listed 'Best First'.
Re: Re: Offtopic: POD directives
by PodMaster (Abbot) on Oct 27, 2002 at 09:22 UTC
    Yes you do. If you're going to bother using pod, use pod as it is defined, not according to quirks in the perl implementation, cause I'll bet you that by perl 5.9 you won't be able to rely on it to work.

    update: Thanks man: "You probably shouldn't rely upon the warn() being podded out forever. "

    update: rir: `perldoc perlpod'. As for things ludicrous pod is not secret stuff.

    update: I ran accross Re^2: Crash Course in POD again, a reply to one of my nodes , and it lists a trick by Larry himself that I like very much ;)(one of the most basic features of pod)

    =for Later for a single paragraph =cut =begin for later Stuff for later =end for later print 'h1'; =begin forlater print 'bye'; =end forlater

    ____________________________________________________
    ** The Third rule of perl club is a statement of fact: pod is sexy.

      From perlsyn

      This means that the following secret stuff will be ignored by both the + compiler and the translators. $a=3; =secret stuff warn "Neither POD nor CODE!?" =cut back print "got $a\n"; You probably shouldn't rely upon the warn() being podded out forever. +Not all pod translators are well- behaved in this regard, and perhaps + the compiler will become pickier. One may also use pod directives to quickly comment out a section of co +de.

      Nah! Your thinking of Simon Templar, originally played by Roger Moore and later by Ian Ogilvy
      I'd be glad to use pod as defined. Point me at a definition. perlsyn contradicts itself.

      There are two sides to pod. What defines a block of documentation for the Perl interpreter to ignore, and the language of pod itself which interpretes the content of such blocks.

      The blank lines are unnecessary in the Perl context. It is ludicrous for Perl to check the validity of your pod when you wish to run your program.

      Are there other plans for the "expecting statement got \n=bareword construct?   If not, why break things?1 Why shouldn't Perl be able to create pod blocks that are null in the pod language? That is hot.


      1 Apologies to whomever was playing with operators assigning to an implied $_ by default.