Re: [gentoo-portage-dev] the refactoring of emerge, continued... (was PATCH: refactor emerge spinner (#102073))

[Alec Warner <warnera6@egr.msu.edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zac Medico wrote:
> Hello All,
> 
> 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).
> 
> 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:
> 
> Variable Name        Dependency
> -------------------------------------------------------
> spinner              search.execute(),depgraph.create()
> merged               unused
> params               unused
> actions              local
> options              local
> shortmapping         local
> myaction             global
> myopts               global
> myfiles              global
> edebug               global
> verbosity            global
> tmpcmdline           local
> cmdline              local
> CLEAN_DELAY          unmerge()
> EMERGE_WARNING_DELAY global
> myparams             depgraph.create(),depgraph.xcreate()
> add                  local
> sub                  local
> 
> 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.
> 
> 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. :-)
  I have emerge rewritten ( somewhere ) for HEAD once all of Brian's
config/domain/crazy stuff goes in, unless someone wants to unlease
modular emerge now, in which case I can pull the code out of the cobwebs
of my ${HOME} and work on it again.

Basically the code allowed you to have a folder for modules that emerge
would detect at run-time, and load the proper ones depending on user
specification.  The bonus to this was that some tools would be merged
into emerge instead of being seperate, which many users got upset about.
"emerge --rebuild" = revdep-rebuild -X for example.  The main problem
with this is basically the same as above; emerge serves about 12
different functions with crappy code everywhere, I managed to replicate
about half the functionality by just copying and pasting important code
everywhere, but most of it still needs to be completely rewritten (
*stabs depgraph* ).  I was going to wait for the new API to be done ( no
use rewriting emerge twice, IMHO ), but if you want it done now it
wouldn't be a big deal.

- -Alec Warner
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQvyXyWzglR5RwbyYAQK07A/+I25MWYwwdaKtNm89UVhgpBadaN+WpMxX
bjgiDFqqoSimNTlIUqWN10w6BM+AXIlvjwCOa8NofjWY5AhgzuM1ULlipSNQ8BrD
Ia20hmVYj2fCJHUx0oU4SZn49BTk1bxtGrDhHHowW3+ERtoo97uuI1ItlUG2gZ/7
Qs8yJs+mPx7dgJsplJOgvWytadNwc4rwiwV6kOq+nOSixY8FSQJwXiZd6YNkjhhE
2vOagT2XwP4MXcaAorlj7z+Nwk+ScW9+X84smMPApEgL0kulsvnVLGqJdNuWUFEa
CwMgv1MIZGGXmtC2/ctaPAKyE3ZQW7pxLzs1T/sjde5Wt7b7bHiXDYpDQfV6agVt
x0dIh36FLSzYYvqSu7wbzgkpJZyWGDDNInIOkRyHgDTwyUVJIoR0w28cTSzjo//G
leLGt5BgXPeHXGzKORRUBUOAaWRUQChL/naSn+I422XXTmoSgm/Fkc+ea7FPX7qr
f7WWARY9Hnx1NCrYJBPB9yTQyPkmAcBD5jf/jR/vEMykgVU49ldEwUVu+J8P57JZ
/YT4xwFw2sTLX4zLU5HxeWArh/m7LGILyt0FzDTzLGKko5WFtXLx2yN9aX6EXSHJ
kfBUQGO84Gkt3d77CIQUrXxjw5Gxxrz9WBOXIe2E6VaAdElRynXoQFLisoCrSs4a
YtRmsEiVJ6E=
=pw6K
-----END PGP SIGNATURE-----
-- 
gentoo-portage-dev@gentoo.org mailing list