SourceForge has been redesigned. Learn more.

Code Assistant that knows my object methods..

  • Markus Dreyer

    Markus Dreyer - 2003-12-01

    Working with Epic is really great. But the most important thing I am missing is a code assistant that knows my objects and pops up a dialog with availabe methods on $myObject->[Ctrl-Space].

    So far, the code assistant knows only some standard module methods, right?

    • Ben Imp

      Ben Imp - 2003-12-01


      If you think about it though, its really difficult to determine what exactly an object is in perl.  In all reality, its just a reference that perl treats as a member of a particular class.

      Since there is no real standard for what function we call to create an object ( usually 'new', but there are no restrictions, as is usual in perl ), we cant just look at the function call that returned the scalar to find out if it is an object or not.

      So instead, whenever one uses the arrow operator on a reference, we must figure out what function created that thing, go into that function if we can find it, and see if it blesses something, and then see if it returns that something - and hopefully then the blessed reference will be in the same class as the package we found it in.  But, as per usual with perl, it doesnt have to be ...

      Doing it in java is easy, there is a concept of a constructor there ... a very well defined concept.  Perl, being so loose, im not really expecting a perfect solution.

      I do know, however, that I can get code assistance on some of my own objects - but only sometimes, and I havent been able to figure out the pattern as to why it happens just yet.  Still investigating.

    • Markus Dreyer

      Markus Dreyer - 2003-12-02

      ... and Java has the nice Reflection package.

      Although a object is just a hash, yoiu cannot just do that:
      my $obj = new MyClass();
      print keys $obj;

      It does not print the contained function references etc.

      But how about the CPAN module Class::Maker? It seems it could be very useful in this context, since it implements just what we need: Reflection for Perl!

      >Java-like reflection is also implemented and allows one to >inspect the class properties and methods during runtime. >This is helpfull for implementing persistance and serialization.

      Maybe with this, the code assistant could look into the objects.

    • Jochen Ruehl

      Jochen Ruehl - 2003-12-02


      what we are currently trying to do is something like this:

      use Net::SMTP;

      foreach $name (sort keys %Net::SMTP::) {
         print "$name\n";

      Is there a better way to do it ?


      • Ben Imp

        Ben Imp - 2003-12-02

        Hm ... well that would allow you to find out all of the "Member Variables" ... I suppose thats the best word for them.

        That wouldnt do much for methods, however.

        I will have to take a look at that Class::Maker module though, this is the first I have heard of it.  It may prove to be quite useful for this ... well possibly anyway.  Im not certain how it could be implimented in Java though, since the actual editor is in Java and not perl ...

      • Markus Dreyer

        Markus Dreyer - 2003-12-02

        Class:Maker does not work, unfortunately. It works only for classes defined in the Class::Maker framework.

        But there is another way to do it.

        A little bit better than

        foreach $name (sort keys %Net::SMTP::) {print "$name\n";}

        is to do it recursively, to get the parent classes info as well:
        sub deep_pool {
            ( sort grep(*{"$_[0]::$_"}{CODE}, keys %{"$_[0]::"}),
              map { deep_pool($_) }
              @{"$_[0]::ISA"} );

        But this gives you only the class methods. But in Eclipse, we want the runtime object methods, resp. first of all we want to know an instance of which class a certain object $obj is.

        I just found a really dirty but okay way to do it:
        Just call something on the object that causes an error message. Get the error message and grep the class name. See getClass() in the code I attached below:

        my $class = getClass($obj);

        It really works! And you don't have to parse the Perl source code to find out which constructor has been used for $obj etc.


        PS: The perl code:

        #!/usr/bin/perl -w
        use Tie::IxHash;

        print "Non-recursive: ", join(", ", pool(Tie::IxHash)), "\n\n";
        print "Recursive: ", join(", ", deep_pool(Tie::IxHash)), "\n\n";

        my $obj = new Tie::IxHash();
        my $class = getClass($obj);
        print "Object $obj has type: $class\n";
            print "Getting methods...\n";
        print join(", ", deep_pool($class)), "\n";

        sub getClass{
            my $class;
            # Get error message indicating the object type!
            eval{$_[0]->NOTEXISTENTCALL} or ($class) = $@ =~ m/package\s\"([A-z0-9]+::[A-z0-9]+)\"\sat/;
            return $class;
        sub deep_pool {
            ( sort grep(*{"$_[0]::$_"}{CODE}, keys %{"$_[0]::"}),
              map { deep_pool($_) }
              @{"$_[0]::ISA"} );
        sub pool{sort keys %{"$_[0]::"};}

        • Ben Imp

          Ben Imp - 2003-12-04

          You can already get the Class name using the 'ref' function.  Give it a try.

          my $obj = SomeClass->new();
          print ref $obj;

          Much better, as there are no errors generated.

          I was more thinking about tryiing to find a way to get the class without having to constantly invoke the perl vm, as that can take a significantly large quantity of time. 

          At work I maintain scripts that are well over 1000 lines of code, and at that size, invoking the perl vm slows EPIC down to the point where I am forced to use the Colorer Scripts Editor or Emacs.  This is my one complaint about EPIC so far, it seems to have trouble with large source files.  I believe the reason for this lies in it continually calling the perl vm to do error checking.

          So im hoping there is a better way to do it than calling perl - but then again, as larry himself says ... only perl can parse Perl.  There may be no other way.

          I will have to take a look at the EPIC source one of these days so I can see exactly what facilities there are for getting this to work.

          • Markus Dreyer

            Markus Dreyer - 2003-12-04

            > print ref $obj;

            Okay, that's much nicer. So, then it shouldn't be an unsovable problem. I wouldn't worry about calling the interpreter frequently.

            Perl6 will be easier to parse anyway, there will be parsing routines to parse perl code, if I got it right.

            So, why don't you do it the slow way for now, just calling the perl interpreter to get the object methods etc? Later, when Perl6 is established, parsing will be easy and you can optimize everything then

            • Ben Imp

              Ben Imp - 2003-12-05

              I dont know that you can get the object methods from the perl interpreter though ... I know you can get the "data members" via the hash key/value pairs, but actual methods are somewhat nebulous from what I remember.

              And then autoloading methods makes things even more fun ... and then multiple inheritance, so your method could be coming from any number of classes.

          • Mike Blackwell

            Mike Blackwell - 2003-12-04

            I've also noticed the slowdown on large files, but more than that I have problems with the timing of the syntax checks.  They tend to start at odd places - in the middle of typing a word, for instance - and don't always run after I stop typing, so leaving the no correct text marked with errors from the previous check which no longer exist.  It has got to the point where I don't trust the markups to be accurate.

            I understand the desire for quick checks on little programs, but for the larger modules, it would be sufficient to check only after typing has stopped for, say, five seconds.

            Perhaps this could be solved by a preference option.  How about an adjustable delay, or possibly a flag to disable automatic syntax checking along with the associated menu/hotkey to manually run the check ??


    • Jochen Ruehl

      Jochen Ruehl - 2003-12-04

      Hi Mike,

      there is a feature request about it (
      If implemented that might solve the problem.
      Another performance problem is due to the outline view. Currently the outline view is badly imlemented. It is refreshed by every keystroke. Here an idle timer could be useful as well.


    • Jochen Ruehl

      Jochen Ruehl - 2003-12-05


      I've changed the code the way that the outline view and the syntax validation are only refreshed if the user does not type anything.
      This is only a test, so code might not be perfect (I haven't checked it into CVS).
      The settings in the preferences have been changed from "Syntax validation interval" to "Validate soure if idle for" to reflect this.
      The test version can be downloaded here:

      Could you please test, if that improves the performance and tell me your opinion.


      PS: New classes/interfaces in the code are and

      • Markus Dreyer

        Markus Dreyer - 2003-12-06

        Something's wrong here. I tested it, and it's really much faster. But actually, no errors in my perl sources were marked at all anymore. Also, there were some other changes: There is no camel icon anymore for the files, but some icons with an "S" in it. So, it's your preliminary version with a bunch of other changes in it, right? At first, it didn't work at all, (java.lang.NoSuchMethodError: cbg.editor.ColoringSourceViewerConfiguration.<init>
                at org.epic.perleditor.editors.PerlSourceViewerConfiguration.<init>(Perl  [Eclipse 2.1.2]

        until I downloaded the newest colorer plugin
        But the strangest thing is, I copied the old perleditor.jar back, and still, no perl source code errors are marked anymore, and the perl files have other icons than before.

    • Jochen Ruehl

      Jochen Ruehl - 2003-12-06


      sorry that things didn't work as expected.
      I've uploaded the whole plugin.

      Could you please test again.
      Hope that it'll work this time.


      • Markus Dreyer

        Markus Dreyer - 2003-12-07

        The IdleTimer works fine now (after disabling the colorer extension plugin). Everything is faster!

        Two improvements would be nice:

        1. It should be possible to disable taint mode
        2. One second should maybe not be the smallest amount of time to wait. It should be adjustable in milliseconds, I suggest.

      • Ben Imp

        Ben Imp - 2003-12-08

        Awesome, it is much improved in speed.  Ill keep using this version and let you know if I find any bugs or grievances with it, but I can say already that this is much more useful to me than previously - I can actually edit my large source files without having to use the colorer editor.

    • Anonymous

      Anonymous - 2003-12-08

      Why was it necessary to disable the colorer extention plugin? I'm very excited about this new timer (I have a slow computer at work) but do prefer the colorer extention over the built in one.

      • Jochen Ruehl

        Jochen Ruehl - 2003-12-08


        the new timer is (at the moment) just a test. So I didn't make the necessary changes to the colorer extensions.
        If you would use the test version with the colorer extension the syntax check would not work.
        I'll try to do all necessary changes (also to the colorer extension) next weekend and publish a new version on the website.

        If you find time, please check the test version and provide feedback.


        • Anonymous

          Anonymous - 2003-12-08

          Great, I'll try it for now and look forward to the new version when it comes out.


Log in to post a comment.