Gentoo Archives: gentoo-portage-dev

From: Zac Medico <zmedico@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] the refactoring of emerge, continued... (was PATCH: refactor emerge spinner (#102073))
Date: Sat, 13 Aug 2005 17:28:27
Message-Id: 42FE2F3F.7000806@gmail.com
In Reply to: [gentoo-portage-dev] the refactoring of emerge, continued... (was PATCH: refactor emerge spinner (#102073)) by Zac Medico
1 Zac Medico wrote:
2 > Hello All,
3 >
4 > The use of global scope code should be minimized in order to prevent
5 > confusion and thereby make code more understandable and maintainable.
6 > After some analysis of emerge's global scope code, I am confident that
7 > all of it can be refactored quite easily, with no regressions or changes
8 > in functionality (reorganization only).
9 >
10 > In order to accomplish this goal, I have categorized the global scope
11 > variables by which parts of code depend on them. The variables are
12 > listed in the following table, in the order that they occur in the
13 > source code:
14 >
15 > Variable Name Dependency
16 > -------------------------------------------------------
17 > spinner search.execute(),depgraph.create()
18 > merged unused
19 > params unused
20 > actions local
21 > options local
22 > shortmapping local
23 > myaction global
24 > myopts global
25 > myfiles global
26 > edebug global
27 > verbosity global
28 > tmpcmdline local
29 > cmdline local
30 > CLEAN_DELAY unmerge()
31 > EMERGE_WARNING_DELAY global
32 > myparams depgraph.create(),depgraph.xcreate()
33 > add local
34 > sub local
35 >
36 > Variables within a given category can be dealt with in a similar
37 > manner. For example, variables with "local" dependency should be
38 > enclosed within a function or method along with the code that depends on
39 > them. Variables with "global" dependency can either remain as global
40 > variables or become instance variables of an object.
41 >
42 > Based on this analysis, I believe that I can quickly create an emerge
43 > refactorization patch for portage-2.1 with no regressions or changes in
44 > functionality (reorganization only). If all (or some) of the portage
45 > developers agree that it is a good idea then I would be happy to create
46 > a patch for all to scrutinize. :-)
47 >
48 > Zac
49 >
50
51 Okay folks, I've done quite a bit of cleanup and I am pleased with the result. I have created a new class called emerge_cmd that encapsulates all of the previously global variables. All of the global scope code has been moved to the bottom so start down there if you want to see how it works. The new class is also at the bottom.
52
53 I had to move so many things around that the diff against portage-2.1.0_alpha20050718 is practically useless. Therefore, I have attached the entire emerge source file. Let me emphasize again that it should be 100% equivalent in functionality to the emerge from portage-2.1.0_alpha20050718. If I have overlooked anything during the refactoring it should be easy to fix.
54
55 I have done some minimal testing and it seems to work well. I would appreciate any feedback.
56
57 Thanks,
58
59 Zac

Attachments

File name MIME type
emerge-2.1.0_alpha20050718-refactored text/plain

Replies