> > >The strong typing of object-oriented languages encourages
> > >narrowly defined packages that are hard to reuse. Each package
> > >requires objects of a specific type; if two packages are to work
> > >together, conversion code must be written to translate between the
> > >types required by the packages.
> If you define the interface well in OOL's, you can handle a variety
> of typed inputs. It's much easier to extend that typing in OOL's than
> with something like C (and have deterministic output). I would guess
> serious programmers do develop their own libraries, or work with
> corporate standard ones (what does Adobe use? they can't be rewriting
> every graphics routine from scratch). Having classes inherit methods
> and types is much nicer than having everything default to a string
> and thinking that's sufficient. MFC is a help for OOP exactly by
> defining libraries that simplify programming. The dangers on
> include that it might come at the expense of too much speed, that
> it might not provide the tools to do everything a lower level
> approach would, or that in doing more complex tasks, the "simpler"
> language actually becomes more obfuscated than the lower-level
having started to use the C++ Standard Template Library (STL) recently, i
must say it totally disproves ousterhout's assertions. the interfaces
are extremely general and because they use templates instead of virtual
members, all the overhead is compile-time. there is no performance hit
for the genericity.
also, i think MFC is perhaps a bad example of how to use C++. M$ has
never impressed me with their API design ability.