I certainly don't want the routine *compiled* each time I invoke the routine. I want it to use the same lexical frame as the variables that the sub is defined in. The only way to do it in perl is to use anonymous subroutines and put a reference into a variable and use an indirect call $var_func->(args), which is not as visually as clear a syntax (in my mind) as "func(args)".
The locals aren't really being crushed...their just in flux....(duplicated, really)....
I took a large chunk of 'inline' code that seemed like it should have its own function and shoved it into a subroutine and started by passing in all of the variables that were needed -- initially about 6 args, with about 3 that were only used inside the code block (so they could become local vars in the subroutine).
Wasn't ideal, but that's why I began shifting and playing with how the code was organized and some params were converted, while some (in the example posted) were still being passed as params...but I was changing them slowly as I was tracking down references in the code and seeing how long the variables needed to be "active".
But that's also how I ended up with a named subroutine -- the subroutine was named for the "functional work" that it was doing. In cleaning/refactoring code, I try to go through and look at parts that are either not clear or are too long or just don't look right. One step in that for me in my own code is "saying what the code does" -- and making that a function-name and moving the code block into the function.
Usually, I'm refactoring to get commonalities out of a code segment so I can reduce code size and have several places use the same code -- in which case, the 'sub' is usually outside of the sub I'm in. But sometimes, I'm simply refactoring because I'm "digesting"...trying to break the code down into smaller more portable bites or pieces, that I can more easily glance at and tell if they are working or not and easily understand them. It could be similar to going through my writing and trying to eliminate the wordiness (I tend toward overwordiness, though I'm sure no one has noticed; :-)) or break apart larger sentences into smaller ones. Occasionally, I can run into a the equivalent of a run-on sentence that takes up an entire paragraph that would be more clear if broken up. If its code I have some time to clean up, I'm usually much happier with it and I'm more likely to be able to pick it up and work with it again in 6-12 months time -- vs. "stream-of-consciousness" blitz filters or scripts to do a task that I want or need to get done.
It's like when I'm thinking about the task or work that needs to be done, it's hard to think about how to also make the instructions of how to do that crystal clear to a third party -- they are different foci, which is why I usually like to work in "passes" -- getting something working so I can begin 'testing' my grasp about what I'm doing... Writing the program is a great way to really flesh out a problem -- since it has to be clearly explained at least well enough that the computer can understand what you meant. Converting that to a readable form makes it into a releasable program.
Does that make sense?
In reply to Re^2: Perl scoping not logical...?
by perl-diddler
in thread Perl scoping not logical...?
by perl-diddler
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |