| 1 |
Hello All, |
| 2 |
|
| 3 |
The use of global scope code should be minimized in order to prevent confusion and thereby make code more understandable and maintainable. After some analysis of emerge's global scope code, I am confident that all of it can be refactored quite easily, with no regressions or changes in functionality (reorganization only). |
| 4 |
|
| 5 |
In order to accomplish this goal, I have categorized the global scope variables by which parts of code depend on them. The variables are listed in the following table, in the order that they occur in the source code: |
| 6 |
|
| 7 |
Variable Name Dependency |
| 8 |
------------------------------------------------------- |
| 9 |
spinner search.execute(),depgraph.create() |
| 10 |
merged unused |
| 11 |
params unused |
| 12 |
actions local |
| 13 |
options local |
| 14 |
shortmapping local |
| 15 |
myaction global |
| 16 |
myopts global |
| 17 |
myfiles global |
| 18 |
edebug global |
| 19 |
verbosity global |
| 20 |
tmpcmdline local |
| 21 |
cmdline local |
| 22 |
CLEAN_DELAY unmerge() |
| 23 |
EMERGE_WARNING_DELAY global |
| 24 |
myparams depgraph.create(),depgraph.xcreate() |
| 25 |
add local |
| 26 |
sub local |
| 27 |
|
| 28 |
Variables within a given category can be dealt with in a similar manner. For example, variables with "local" dependency should be enclosed within a function or method along with the code that depends on them. Variables with "global" dependency can either remain as global variables or become instance variables of an object. |
| 29 |
|
| 30 |
Based on this analysis, I believe that I can quickly create an emerge refactorization patch for portage-2.1 with no regressions or changes in functionality (reorganization only). If all (or some) of the portage developers agree that it is a good idea then I would be happy to create a patch for all to scrutinize. :-) |
| 31 |
|
| 32 |
Zac |
| 33 |
-- |
| 34 |
gentoo-portage-dev@g.o mailing list |
Archives