|
From: Frank V. C. <fr...@co...> - 2000-01-27 04:56:21
|
I received this from Joe although I believe his intention was to float by us all. > Just recently I got an idea about a new way (at least it's new to me) of > designing a C++ framework. It's based on the toolbox metaphor that I've > heard applied to software components. The easiest way for me to contrast > this new design with current systems is by an example. > > Currently, if a programmer wants to use a C++ collection class, they > think in terms of arrays, linked lists, stacks, queues, etc. They select > the right one for their needs based on the speed tradeoffs of its method > functions. Fundamentally, these abstractions do the same thing: store a > pile of related data. A programmer thinking in terms of the toolbox will > see these abstractions all as a type of hammer, a collection hammer. > This idea of subclassing is nothing new; what is new is the way this > programmer selects a collection "hammer" from the toolbox. The > programmer thinks about the problem at hand, and makes his speed > tradeoffs explicit. > > Let's say that the programmer wants a collection "hammer" that is > optimized for insertion and deletion of data items. Rather than just > instantiating a linked list, he asks the computer for a collection type. > He specifies that he needs an average random access time of O(n/2), a > worst-case random-access of O(n), and a constant insertion/deletion > time. (By the way, I don't know if these values are realistic -- they're > just for the sake of explanation.) The computer then looks through > whatever collection classes it has, and finds one that matches these > specs. If it can't find one, it throws an exception and perhaps even > makes a recommendation for the next-best class that is available in its > toolbox. This way, programmers' toolboxes could be filled from classes > off the net, and the computers would be responsible for making a match > between what a programmer requests in his program, and what his toolbox > actually holds. > > The idea gets powerful when you start to consider the whole computer, > hardware and software, as items in a toolbox. Wouldn't it be nice to ask > the computer for a soundcard tool in the box, and specify that you want > one that has wavetable MIDI synthesis, if possible? > > The whole idea rests of finding the correct tool hierarchy and being > able to quantitatively assign fitness values to certain operations on > those classes. Several types of class operations lend themselves > especially well to this quantitative rating, as was demonstrated by the > example of the collections' operations being rated by algorithmic > complexity. I think numerical hardware capabilities like screen > resolution, duplex capabilities in soundcards, and printer speed also > are perfect candidates for "toolboxing." I've seen this idea of > requesting capabilities before in Microsoft's DirectX, but its > application across the whole hardware/software spectrum is what seems > novel to me. > > So is this idea so old that Knuth taught it to his dinosaurs? Does it > have any merit? > > --Joe Nelson --- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux |