in reply to Annotations for Perl

In Perl, a subroutine/method can return various things, depending on context, but also the arguments, global state, local time, etc. I'm not saying it's a good habit, but an IDE should help you program, not restrict you. Perl programmers don't write Java in Perl, the thinking is different, and with enough experience, it leads to organised code, too, but organised in a different way. Being dynamic isn't Perl's weakness, but strength, when used properly.
لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

Replies are listed 'Best First'.
Re^2: Annotations for Perl
by hurricup (Pilgrim) on Jun 02, 2015 at 17:19 UTC

    Yes, i know that. But there is a big difference between writing one-string and production OOP code. For first- you don't need IDE

    My purpose is to make tool for people developing readable structural projects, not for perl magicians :)

    And after all, do you have an alternative solution for described problem?

      Yes, i know that. But there is a big difference between writing one-string and production OOP code.

      choroba is talking about "production", he is not talking about "one-string"

      My purpose is to make tool for people developing readable structural projects, not for perl magicians :)

      Why would those people start with a code editor, instead of some UML code generating tool?

      And after all, do you have an alternative solution for described problem?

      Module::Info, Doxygen::Filter::Perl,.... :)

        Module::Info says itself that it's unreliable in this part, Doxygen is fine, but we've got de-facto standart as pod and previously been suggested, there is a =for