[Corelinux-public] Re: Joes "toolbox" programming straw man

[Frank V. C. <fr...@co...>]

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