On Wed, 12 Nov 2003, Michael Stenner wrote: > > where command is one of 80 different options. > > > > I don't think that is good design and can you imagine that if statement? > > ;) > > I know you were just joking (the smiley gave it away) but there is a > tidy solution to the "endless if" problem. > > Make a dict[] of names->functions. This makes the whole thing rather > modular and tidy. Define the functions wherever you want, including > 'plugins' if you like. In one place, you stick them all into the > dict, and then you just do: > > try: > command_dict[command_name](command_args) > except KeyError: > print "no such command" > > I'm not arguing for rgb's suggestion. I'm just pointing out that this > is often a nice way to deal with really long ifs :) There are several ways to proceed. I'm inclined to argue (again) that at some point it makes sense to split the single yum client (with lots of increasingly divergent suboption arguments) into several clients with a common or nearly common command option organization. In the past we've discussed this -- making informational commands into yuminfo, leaving the install/update commands in yum itself and maybe adding e.g. yum configure, adding another tool altogether (which I really will try to contribute as I have time to learn python and crank through it) to create a compact configuration snapshot of an installed system, adding STILL other tool(s) to function as GUI and so forth. Although I don't think it is absolutely necessary yet, at some point the core libraries and API can be more or less frozen and be distributed as yum-devel, the toolset can be bundled up as yum-tools, the GUI(s) as yum-gui. All of this is straightforward. The thing to remember is that documentation and organization are the mediators of complexity. If the yum client becomes too complex as it embraces too many hierarchical functions, split it up into separate hierarchies and document heavily. Documentation actually becomes EASIER with hierarchical decomposition. So does maintenance -- with a good hierarchical decomposition it is relatively easy to divvy up maintenance and development and documentation as no one person needs to be "in charge" of all three for all tasks... rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
