Path: utzoo!attcan!uunet!lll-winken!ames!ucsd!rutgers!att!mtuxo!rolls!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: Improved switch statement (was Re:
Summary: He said OBJECT!  I say, don't always OBJECT!
Message-ID: <140@mole-end.UUCP>
Date: 10 Jan 89 08:01:47 GMT
References: <574@redsox.UUCP> <77300019@p.cs.uiuc.edu>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 94

> When I say that virtual functions are "better" than switch statements,
> I mean that they result in programs that are easier to understand and
> maintain.  ...

I agree, for those places where the paradigm is appropriate.  Bjarne writes
that if you can think ``it'' as an idea, make it a class (a type); if you
can think if ``it'' as an entity, make it an object.

BUT ... where the ``it'' is wholly abstract, for instance a finite set of
some sort, and where the ``it'' is part of a larger abstraction (directions
of cursor movement in a terminal window package or the state of a call
appearance at a telephone set) it may make more sense to represent it as an
enumerated type.  The compiler can check that the switch statements cover
all of the cases; the grunge is limited to one class, and should you need to
pass the info around you can create a package class, all private with your
main class as a friend, the package class containing just one member of
the set-member type.

If you insist on representing states as objects of a class type, then you
have an explosion of member funtions: member function T::a is what S::a
has to call when *it* needs something done depending on the case, T::b1 and
T::b2 are what S::b have to call, etc.

Worse, you will either need to make the members of T friends of the appropriate
members of S, or create yet a new type for transactions between S and T .
This is a path to infinite regress; at *some* point you have to talk about
basic types, at least in C++, and enumerations on states of ONE other type
(perhaps a even a base type for other classes) seems like a clear and
economical place to take that step.

In teaching myself C++, I've carried ``classiness'' a little too far on
occasion, and this was one of the paths I wandered down.

> >This too makes some presumptions: that OOP is necessarily more elegant than
> >non-OOP and that more-elegant is better than not-more-elegant.  The latter
> >is dangerous; ``elegant'' and ``tricksy'' are too easily confused.
> 
> I disagree that elegant and tricksy are at all similar.  In my book,
> elegant means "simple and easy to understand".  It does not mean fast,
> small, or anything else.  ...

In the practical world, you do have to shoot for all those goals, no?  And
one path to elegance is to take advantage of some particular data or
knowledge representation which can be interpreted in different ways depending
upon your viewpoint, producing (by coincidence) consistant results as you
move from viewpoint to viewpoint.  Such things aren't bad when they are
encapsulated and described as conversion mechanisms; they are disasterous
when they are scattered throughout code which treats the coincidence of
the viewpoints in cases A through N a fundamental property of the problem,
breaking the code for cases N through Z.

This confusion does take place in the real world and it is sometimes
exploited to very good end.  And it has come to be one definition of
``elegant.''

I'm pretty well convinced that there is a class of problems which the OOP
paradigm does not handle well, at least as it is implemented in C++, and
that C++ allows these problems to be expressed without preventing the OOP
paradigm from being used on other problems within the same program, even
when the two must communicate and cooperate.

> If it is possible to write a bug-free operating system, elegance is
> a prerequisite.

Which definition of elegance?  I would say that clear thinking is essential.
Clear, comprehensive, and economical expression are essential.  The OOP
paradigm is certainly a powerful tool.  So is a table saw.  But not every
job is best done using a table saw.

Can you demonstrate convincingly (not necessarily to the strict standards
of proof) that in C++ the OOP paradigm is always the ``best'' one to use?

> 			       ...  In my book, there should be an abstract
> class that defines 11 virtual functions and 7 concrete subclasses.  If you
> want to add a new case in the C-like version then you will have to go find
> all 11 places you had a switch statement and fix them up.  ...

You might.  Determining which will be easier and safer to modify is often
an engineering judgement.  (At least if you use enumerated constants and
you avoid default cases in these sets, the language processor can help you
identify the places that need change.)  Engineering judgements often depend
for their soundness upon the soundness of your reading of how the program,
project, or product will be expected to grow in the future.  For the time
being, experience properly used is more valuable than any textbook education
that I know of.

> I love a good fight.  Thanks, Mark!

I'm pleased that I meet your standards for an adversary, but I'm not sure that
I see this discussion in quite that light.
-- 

(This man's opinions are his own.)
From mole-end				Mark Terribile