in reply to Perl editor idea

The idea in itself sounds useful, being able to navigate through code, but not for the reason you gave. Also, why stop at comments/labels? Why not make it figure out which variable is defined where, and take you there when you click on the variable itself? Then you just need to write the comment next to the place the variable is first created. The same would be useful for subroutines as well. (In fact the VB IDE does something like this, though it doesnt jump back to where you came from, I wish it would.)

And while you're at it, and storing subroutine names/definitions etc, you could make it automagically fill in subroutine parameter skeletons.. Oh, wait, VB does that too :)

As the rest have said though, this is like closing the barn door after the horse has bolted. Don't attempt to fix your bad programming with a better way to keep track of it, fix the programming instead. If you have three arrays that need to be changed simultaneously (though that sounds as if it should be one structure, then), make a subroutine that does just that, and call it instead.

Lastly, no, I wouldnt want a spider that ignores robots.txt, its there for a purpose.

C.

Replies are listed 'Best First'.
Re: Re: Perl editor idea
by Chady (Priest) on Jan 14, 2004 at 10:11 UTC

    There's OptiPerl which does something like that.

    I only used the trial version for a while, it even looks up subs from modules and also shows objects properties and functions -- like VB ;) -- etc,

    I'm still wondering if I should buy it or stick to gVim -- after all, it helped Marry.

    He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.

    Chady | http://chady.net/
[reply]
      There's OptiPerl which does something like that.

      The world does not need development tools that make bad code easier to write.

      -- Rocco Caputo - rcaputo@pobox.com - poe.perl.org

[reply]
Re: Re: Perl editor idea
by Wassercrats (Initiate) on Jan 14, 2004 at 10:53 UTC
    Why not make it figure out which variable is defined where, and take you there when you click on the variable itself?
    I thought of that, but I don't want to have people writing scripts that are only understandable when viewed by a special editor. My way, with comments for each instance of a variable, you'll never miss them. But if I added your feature, I'd probably have the variables for which there are global comments be a certain color, so maintainers wouldn't be clicking every variable, hunting for an explanation that isn't there.

    The three arrays don't always have to be changed simultaneously, but they have to be kept the same length. If I add to one and decide I don't need the element, I only have to cut from one. If I used a tiny subroutine for that, it would have to compare lengths to see which arrays need to be spliced and if they're the same length, truncate all of them, else I'd have to pass the subroutine the arrays to truncate. Either way, it would take about as much code and be clearer if I duplicate the specific cut routine I need wherever I need it. Comments before each subroutine call would be a good idea too, so I wouldn't be eliminating any comments.

[reply]

In Section Meditations