> Basically you have a class/module per [command] which you instantiate > based on the value of [command] and pass all the subsequent arguments > too. The core yum main() entry code doesn't even have to know what > commands are available. > > Adding new commands would be a case of dropping in new classes/modules > with the catch-all set to spew out the usage/list of valid command options. > > You don't need an if block or a dict at all - hell you can even build it > in such a way that the command documentation is dynamically pulled from > the class the command is in: > > bash$ yum list help # calls commands.list.usage() > > <quote> > > GIVEN A LONG LIST of name->function pairs, how do we more cleanly > deal with them? > > </quote> > > Answer: you don't have a long list. You use introspection/reflection. > Why build a mapping when you can derive it at runtime? That's fine but that still doesn't make finding anything in the requested commands any easier. The whole point is to make something that runs simply and correctly w/o having to learn 80 options. This is not ls, this is not tar. I don't want to have to have a 40 page man page. That makes no sense, imo. I'd like to write a nice library that other programs can use. That way people can write whatever they want, hopefully, with ease and there can be greater expansion and growth in the number of useful tools out there, rather than cramming everything into one tool. -sv
