Over the many years of development of this toolkit by many independent developers, several bad things have been growing to intolerable proportions:
- only one executable, vision.C, had complex command-line parsing capability, although in principle many other executables could have had such capability through the OptionSet and OptionParser classes. Thus, vision.C had become the only program that could be tuned to do various things using command-line options, and as such people would keep adding new stuff into vision.C to the point that it had become an incredibly complicated mess;
- many little programs were developed to test out and use new classes added to the toolkit. Typically those programs all shared substantial components (e.g., get a bottom-up visual attention model going, which meant instantiate a bunch of ChannelBase derivative objects, a VisualCortex, a Brain, etc), which was achieved through cut-and-paste from similar programs. Consequently, any core modification of the toolkit required updating of all those duplications of code.
- people had a tendency to develop undocumented classes in their little corner, and the lack of doc and availability to core programs would make this unknown to other developers; thus, several almost-equivalent classes had been created for, e.g., access to a serial port and other functionality.
With release 3.1 of the toolkit in early 2003, we attempted to fix those problems through the following strategy:
- a mechanism was implemented to create tunable model parameters, whose values could be easily set via the command line or via config files. A set of classes (ModelParam, ModelComponent, ModelManager) was provided to ease the management of hierarchies of model components that would have such tunable params, and to automate the process of tuning those parameters via the command line or config files.
- thus, vision.C was obsoleted and replaced by ezvision.C, which is a truly minimalistic program. Instead of doing all the work of parsing the command-line and deciding what to do based on the command-line options in the main() of various programs, that work was shifted main() to where it belonged in the first place: the various components of a model. The main paradigm shift, hence, was that a given model component (e.g., VisualCortex) should itself declare which of its parameters could be tuned, rather than the main() of vision.C or other executables deciding on that. With this new framework, adding a new tunable parameter to a given model component would automatically make it available to all programs that used that component, without any modification necessary on those programs' main() function.
- ModelComponent was developed to be a base class for substantial computational modules of a neuromorphic model. The functionalities included in the base class (mechanisms to build hierarchies of ModelComponent objects, automatic setting of ModelParam values via the command-line, etc) would not need to be duplicated anymore as it had been the case previously.
- Hopefully, documenting code and making it available to other programs should become more common in this framework too; indeed, if you wish to introduce new functionality into ezvision.C, typically you should not do so by adding code to ezvision.C itself, but rather by adding new components or new parameters to the existing components that are used by ezvision.C.
Thus, the main idea behind revision 3.1 was to push as much code as possible out of main() and back to where it truly belonged in the first place, scattered across the various components of a model. See here for a quick overview of how this was implemented and how to use this framework to build your new classes and models.
1.6.3