New to OO concepts - re-usability

[Alex Martelli]

"Chris Hanson" <cmh at bDistributed.com> wrote in message
news:220220010813598042%cmh at bDistributed.com...
    [snip]
> STL was designed by number crunchers with the broken assumption that
> programs are designed from the algorithm out and that efficiency is the
> absolute most important goal.

If C++ is being used, then efficiency *HAD BETTER* be a paramount
goal: otherwise, the programming-language choice was utterly absurd.

> Software in the real world is designed

...in utterly absurd ways, very often, sure -- such as, using C++
for stuff that it's simply ridiculous to do in C++, as it does not
really need its runtime efficiency (and thus, should absolutely *NOT*
be paying the huge programmer-productivity costs connected with
C++ memory management &c).

But the STL designers were quite right not to take this into
account -- their key goal was to make C++ better *for the uses
to which it SHOULD be put* (which in turn implies, cases where
runtime efficiency is important) rather than for uses to which
it should NOT be put (although it often IS:-).


> I've actually had STL proponents tell me it's a *good* thing that
> std::vector<T> doesn't have a push_front() method because if you try to
> do that your code won't compile and you'll know you should be using a
> "more efficient" container class!

Yep.

> What if I *know* it's an expensive
> operation, I know I need to do it occasionally, and I need the speed
> that std::vector<T> will otherwise give me?

You don't make believe a METHOD exists, but rather call a FUNCTION
for the purpose.  E.g.,

template <class X>
inline void push_front(std::vector<X>& vec, const X& x)
{
    vec.push_back(x);
    std::rotate(vec.begin(), vec.end()-1, vec.end());
}

> "Subclass std::vector<T>
> then!"  (This was the real answer they gave.)  If I have to subclass a
> standard container class to get simple functionality, it's *not*
> well-designed.

The STL designers are not *class-obsessed* (the way you seem to
be, and, apparently, those 'STL proponents' you asked -- the
very *idea* of subclassing STL classes is laughable, so, they're
proponents of what they don't really understand).  Lots of
important functionality is packaged up as _function_ templates,
and is meant to be called with function syntax.  The 'algorithms'
thus packaged are _orthogonal_ to the container classes.

You don't have to subclass anything to 'get simple functionality':
you call functions, when that is more appropriate than calling
methods (funny enough, Python is based on this concept, too:-).

Apparently, you refuse to consider that calling a function can
be THE way to access functionality; and thus, to consider "well
designed" a class if it has methods to duplicate any "simple
functionality" that is in fact quite accessible with slightly
different syntax-sugar via function-calls.

Well, I have news for you -- those classes you seem to think
are "well designed" are what many of us would think of as "fat".

*MY* idea of a well-designed class, **for a language that has
free-standing (templated or dynamically typed) functions** as
well as classes, and thinking of foundational library classes,
is one which exposes a LEAN (but functionally complete) set of
methods, allowing a separate set of "convenience" functions to
do their job neatly.  Not 10 classes with 100 methods each,
as 10 * 100 == 1000; rather, 10 classes with 10 methods each,
and the other 90 things factored out as functions -- 190 is
a much smaller number than 1000, so the overall design is
simpler and leaner.


Alex