Feature Request: Code Assist for arguments

  • Michael Fuchs

    Michael Fuchs - 2007-04-24


    Code Assist is presently not working for variables/objects that have been passed to a function as arguments, i.e.:

    sub foo : Local {
        my ( $self, $c) = @_;

    I'm presently working on a project which is based on the Catalyst framework, so I have constructs like the above all the time. As $c in this case is my Catalyst object, I need to access its methods quite often and it would be great to be able to use the Code Assist feature for this.

    Maybe it would be possible to declare the object in some kind of perldoc way to tell epic how to handle them.


    • Jan Ploski

      Jan Ploski - 2007-04-24

      Dynamic type inference without additional clues would be very difficult and at times impossible to accomplish. I was also thinking about "perldoc"-like annotations to solve this problem. In fact, I was thinking javadoc-like, not perldoc-like because POD is very lax about documentation conventions.

      It would be much better to support an IDE-neutral specification convention for Perl API documentation rather than invent hacks for EPIC. The trouble is, I am unaware of any such convention (possibly it would go against the official language philosophy?) There is a doxygen filter for Perl which goes a step into the right direction (http://www.bigsister.ch/doxygenfilter), but it doesn't actually define useful conventions for describing types of parameters or return values (which is disappointing). I also don't think that the doxygen filter is widely used enough to serve as a "standard".

      Another approach (in the hacks for EPIC category) might be configurable naming conventions (so that you can say that a variable named $dbh always refers to a DBI object).

    • Michael Fuchs

      Michael Fuchs - 2007-04-24

      As I only know two IDEs for Perl, Eclipse and Komodo, and Komodo doesn't support anything like it either, I would just go for the hack :)

      Maybe it would be possible to set both global and per-function naming conventions ?


    • Matisse Enzer

      Matisse Enzer - 2007-04-25

      The PPI module might help, but I agree that some sort of annotation seems like a good solution. Such annotation could even, someday, be used by Perl itself.

      sub foo : Local {
         my ( $self, $c) = @_; # @TYPES( MyClass::MyObject, Catalyst )

      • Jan Ploski

        Jan Ploski - 2007-04-25

        If we are to believe the following page, Perl 6 is going to have type annotations and there is already a syntax for it. Unfortunately, no mention of a format backwards-compatible with Perl 5 is made:


        • Michael Fuchs

          Michael Fuchs - 2007-04-25

          I see. That sounds like a good thing.

          The bad thing is that we might have to wait quite some time until we can use that feature.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks