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

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

[snip]
> > 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

I like it.

From a static standpoint, where the developer chooses at development
time objects based on some characteristics, it is as easy as
specification detail reading and understanding their problem domain
requirements. And of course the classes that fill those requirements.

From a dynamic standpoint, I don't know about dinosaurs but your idea
crosses a couple of area borders both old and new. The following are
those areas which you are bringing into play, I can further describe
them if anyone wants.

1. Resource loading - needs -
2. Resource monitoring
3. Dynamic Configuration -needs-
4. Constraint solving
5. Registration and resolution

This is a more complex approach, and because of that even more
interesting.