in reply to Re^2: Comment blocks & private methods
in thread Comment blocks & private methods

Except to parse comments correctly you have to parse perl, because knowing where a string (or string-like anything) starts and ends is really complicated (there are so many ways to start a string in perl that can be nested into each other that you have to parse the whole file correctly to be sure wether one part is code or a string), you wouldn't want your parser to change: "You can also use C-like comments: /* */" into "You can also use C-like comments: " or /\/*\*// # yup, good coding style into /\/ # that works just fine.

I didn't have that point in mind when I wrote my comment though.

Edit: in the end yes, POD may actually be the best idea. My bad :D

Replies are listed 'Best First'.
Re^4: Comment blocks & private methods
by LanX (Saint) on Dec 12, 2014 at 16:50 UTC
    > I didn't have that point in mind when I wrote my comment though.

    yeah see my update, (coevolution of better ideas! ;)

    > Edit: in the end yes, POD may actually be the best idea. My bad :D

    maybe a good feature request to to make empty =for without FORMAT and surrounding blank lines official for multi-line comments

    print "start - "; =for bla bla =cut print "stop!";

    My perl-parser as well as perldoc ignore those lines. Only emacs' cperl-mode insist on surrounding blank lines.

    Cheers Rolf

    (addicted to the Perl Programming Language and ☆☆☆☆ :)

      Well, if there's a change to include multi line comments, you might as well choose something that doesn't look like what its not and introduce specific syntax (although POD comments have the advantage of not breaking backward compatibility), it's not just about the parsers, it's also about people reading the code (when you get used to POD containing useless code, you may ignore perfectly useful documentation embeded in the code). And well, if the feature still isn't included in perl after all those years, it's certainly not because no one ever thought of a solution, it's on purpose (I'm pretty sure I read somewhere that Larry Wall doesn't like them, for some reasons (and there are good reasons)).

        I like the empty =for solution b/c it's concise (only four letters¹) and backwards compatible and you can easily extend it by adding a format.

        Though as long as it's not documented some pod-parser might fail if no format is given.

        I think Larry might not like them cause /* ... */ might be easily overlooked and therfore people tend to indent the text in between.

        > (when you get used to POD containing useless code, you may ignore perfectly useful documentation embeded in the code)

        POD is rarely interspersed like in literal programming, and personally I never tend to ignore it more then comments.

        Take a look into perl5db.pl as an example.

        Cheers Rolf

        (addicted to the Perl Programming Language and ☆☆☆☆ :)

        ¹) With Python needing 3 doublequotes """ this seems a compatative solution.

        update

        Though POD fails if you need to adjust to surrounding indentation. There is a reason why one should always look up older discussions. ;)

      My perl-parser as well as perldoc ignore those lines. Only emacs' cperl-mode insist on surrounding blank lines.
      IIRC, older POD parsers required blank lines around command paragraphs.

      --MidLifeXis

        True but it's not meant for POD anyway, as long the compiler ignores it it's fine.

        Cheers Rolf

        (addicted to the Perl Programming Language and ☆☆☆☆ :)