 |
 |
 |
A Thought Experiment: The Results |  |
 |
 |
ui GUI toolkit
In the first place, it may seem like cheating to create and employ a GUI toolkit that has no graphical display (no problems with component layout, for example) and no user-initiated events to worry about, and that is precisely the point: it is cheating! The whole idea is to investigate an application framework (and notation) without getting bogged down in the kinds of details typically associated with a GUI toolkit. These issues cannot be ignored indefinitely, of course, and in fact these concerns are crucial to custom application development, but the whole idea of the Thought Experiment is to forget about these details long enough to work through what I consider to be more important and more central issues.
On the other hand, it may seem that idealizing a GUI toolkit in this way doesn't actually buy us very much, that the application framework we come up with using this ruse will simply be an amusing diversion without any real benefit. That remains to be seen, I suppose, but (1) if the idealization is done in such a way that the API is realistic, and (2) if the framework does not rely upon special features of the idealized toolkit, lessons learned here should apply equally well when we are ready to take on the real world GUI toolkit.
Additional background and rationale for idealizing the GUI toolkit can be found at Rationale 2, and the implementation is described in the next section of this document, Results 2.
It is not unusual for software to evolve, nor is the step-wise development of software a novel strategy. In fact, one of the strengths of Python is how it facilitates an evolutionary development style. What may be innovative about the Thought Experiment is way in which the incremental steps are chronicled through a sequence of unit tests using inheritance.
What I am talking about here is defining (and testing) Python classes one or two methods at a time, where each version of the class is named with a suffixed version number (such as Cell_020), and each version inherits from a version defined and tested in a previous step.
class Cell_020(Cell_010): # more class definition # ...
This technique is especially effective when the only change is the addition or modification of (overriding) a given method. When additional attributes are also required, usually the __init__ method needs to be overridden as well, and in this case I have generally reproduced the entire method with modifications rather than calling the superclass version of the method. This is because: (1) most of the __init__ methods are short anyway; (2) they consist primarily of assignment statements; (3) it is often helpful to see all of the initialization statements in one place; and (4) sometimes the sequence of statements must be changed.
The unit test is a powerful tool in agile programming, and the PyUnit testing framework particularly well suited for our purposes. The Thought Experiment consists of a sequence of unit tests, each written to test a feature of the AP framework as it evolves. If there is any aspect of this technique that is innovative in the context of the Thought Experiment, it is that two copies of each unit test are maintained. The first one tests a specific version of an evolving class, and the second one tests the same function for the cannonical version of the class (as it evolves). The second copy thus becomes part of the regression test suite to assure us that the final version of the class has not been broken by one of the incremental modifications to the source code. In the rare occasion where the newest version is not backward compatible with a previous version, one or two lines are commented out of the unit test (but left there as a comment).
|
XHTML 1.0
© 2003 Donnal C. Walter,
This page updated 2003-12-07. See About this document for information on suggesting changes. |