On Monday 17 September 2007 19:44:10 James E Keenan wrote: > The current system consists of 58 separate programs which vary markedly > in terms of purpose and complexity. The only things they share in > common are (a) that they are required to have a $description and a sub > runstep() to fit into the harness run by Parrot::Configure::runsteps and > (b) that they return either a Parrot::Configure::Step object or 'undef'. > The most common reason to place code in a subroutine is code re-use, > but none of the 58 different step runstep() subroutines is ever re-used.
That may be the most common reason to place code in a subroutine, but it's certainly not the best reason. The benefit of each configuration step having a runstep() sub is that they share an interface, which gives polymorphism or genericity depending on where your design tastes lie. The benefit of polymorphism or genericity enabled by a well-defined interface is encapsulation. > The fact that virtually all the functionality of any particular Parrot > configuration step is packed into a single runstep() subroutine means > that for such a subroutine it is darn near impossible to follow the > maxim, "Have your subroutine do one thing and do it well." > It also means -- and here comes the place where I have major ego > investment -- that many of the step runstep() routines are difficult to > test thoroughly. The benefit of encapsulation is that you don't have to know *what* goes on behind the interface. That is, just because the configuration steps have to have a runsteps() subroutine with the appropriate input and output, each subroutine can do whatever it needs to do inside -- especially calling other functions which *are* testable because they're well-encapsulated and well-factored. In a nice chiasmic coincidence, this gets me to the best reason to place code in a subroutine: decomposing a problem into individual units that you can name often makes for much better code. Certainly it makes for more testable code. I'm very much not an expert on the configuration system, though I've patched it a couple of times. I think the problem isn't that the overall design is bad, just that the design-in-the-small of individual steps is less than stellar. -- c
