Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: How to find all the available functions in a file or methods in a module?

by jplindstrom (Monsignor)
on Nov 11, 2008 at 13:44 UTC ( #722851=note: print w/ replies, xml ) Need Help??


in reply to How to find all the available functions in a file or methods in a module?

Obviously there isn't ever gonna be a 100% solution for a language as dynamic as Perl. Even if you had some kind of internal reflection capability at runtime, you can't account for an AUTOLOAD that hasn't been run yet. And for textual parsing you can't find dynamically created methods and attributes.

In PerlySense I take a heuristic approach to identifying methods.(And I don't distinguish between methods and attributes.)

Basically, Perl code has a lot of conventions and idioms. If it looks like Perl, let's assume it is Perl. So if you look at Perl code and see this, what would you say it looks like?

$self->send_email();
It looks like a method on the class for the current package. So let's assume that's what it is. In the same vein I take the shortcut of considering this a method/accessor:
$self->{email} = $recipient_email;

If PerlySense can't find an explicit declaration for a sub or attribute (mostly attributes), it will look for matching POD to display or navigate to.

How you interpret things kinda depends on whether you consider false positives or false negatives worse. Maybe some positives are worse in some situations and negatives worse in others (possibly completions vs refactorings). Just looking at methods invoked on $self is not gonna find all of them, but static parsing of "sub" + $self->method and $self->{attribute} turns out to be pretty complete.

When it comes to static parsing of syntax, I guess we'll need to write plugins to accompany module-introduced syntax for Moose, Class::Accessor, Class::MethodMaker, etc.

I haven't done anything like that yet, but there's enough Moose classes in the code base at work that I'm really starting to miss a working "Go to Base Class" for the Moose stuff.

/J


Comment on Re: How to find all the available functions in a file or methods in a module?
Select or Download Code
General tagging support
by LanX (Canon) on Nov 11, 2008 at 14:20 UTC
    Obviously there isn't ever gonna be a 100% solution for a language as dynamic as Perl...

    ...I guess we'll need to write plugins to accompany module-introduced syntax for Moose, Class::Accessor, Class::MethodMaker, etc.

    Hei J!

    I just had a similiar idea to switch the responsibility from the IDE to the modules author, so I paste my thoughts in reply to yours. 8 )

    From a bigger perspective ... IMHO the conceptionally best approach for IDEs would be to define an interface for authors to communicate which methods and subs their modules generate. So authors have the responsibility to export their tags.

    For instance an additional module for Class::Accessor, let's call it Class::Accessor::Tags may have the necessary parsing logic for the to-be-tagged module.

    Or maybe for more dynamic generations "::Tags" may just override subs like mk_accessors() in a way that executing the code doesn't really run but just produce the tag-infos.

    Saying this it's unlikely that module-authors will do this extra work just to support Padre and the OP would maybe not want to support all open IDE's like Emacs and Vi.

    So a general IDE-independent standard would be needed!

    UPDATES:

    Talking about "tags" it may seem that I'm favourizing the format of ctags or etags as appropriate interface (just look at the manpage *), but I'm not sure... not knowing a better alternative doesn't mean that there is no better choice. Anyway IMHO most IDEs support tag-files, making them to a de facto standard.

    * some links: http://en.wikipedia.org/wiki/Ctags http://ctags.sourceforge.net/

      Yes, an IDE neutral "standard" would be wonderful. Given the momentum of Padre at the moment, hope the lower layers of it will be fully reusable across other editors.

      Regarding exporting, I think that just declaring method names would be too limited for some uses.

      For instance, for refactorings (let's say "Rename Attribute"), the refactoring code needs to know not just the name, but which part of the source tree specifies the name.

      /J

        > Yes, an IDE neutral "standard" would be wonderful.

        well, ctags is quite independent, extendebal and universaly used. But AFAIS it relies on regex-patterns, which is to limited for perl... but better than nothing.

        By intuition I think perl-parsing needs to compile the code like flymake-mode in emacs does to find syntax errors. (hmmm...does it?)

        But the "IDE-logic" per module should be supplied by the module/submodule. This way one could decide which module to use dependend on it's IDE support.

        > Regarding exporting, I think that just declaring method names would be too limited for some uses.

        of course not, the intention of the OP is just a peace of the spektrum. : )

        Cheers

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://722851]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (8)
As of 2014-07-29 02:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (211 votes), past polls