From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Organization: Object Systems
Date: Sun, 11 Oct 1992 00:22:00 GMT

[This is a response to article <1992Oct4.150650.9408@ucc.su.OZ.AU>
 maxtal@extro.ucc.su.OZ.AU (John MAX Skaller).  It is summarized to save
 time and bandwidth.  My apologies for a late response; this is the first
 chance I've had to reply.]

[John: Why dynamics?]

Many languages such as Smalltalk, CLOS and Objective-C provide dynamics.
The full power of dynamics is *required* in many circumstances.  It is
required when the information to make calls is not available at compile
time.  This occurs with any environment in which objects and classes can be
dynamically added at any time, such as with GUI's.  It is also more generally
required when various objects must be accessed.  For example, start with a
GUI and a GUI_Object class that any object must be derived from (strict) to
be presented to users.  If you want to add new classes and objects, statics
alone can't handle it.  If I want to pass any message to particular objects
in the environment statics can't handle it because the (empty) GUI_Object
interface is all that is available.  With unchecked dynamics; however, the
message is simply passed to the object to see if it can handle it.  With
downcasting, the object's type is determined and then the message is given
a try.  With statics, you're left with a mess such as moving all derived
object methods into the GUI_Object class with a default behavior of not
handled.  This doesn't work for dynamically added objects and classes, and
just creates a big mess for the simple case that it can handle.  What if
a programmer adds a new method to a derived GUI_Object but forgets to
move it into the GUI_Object class as a virtual?  This redundancy is most
undesirable.

Therefore; John, it *is* most desirable to access objects based on their
dynamic types in advanced applications, to do otherwise is the exception
and not the rule!

And these environments require some form of dynamics, there is no way
around it.  I've worked in environments that require it for years.  You
can hack a solution with idioms or use language support, but it must exist
nonetheless.  To reiterate, these common applications COMPLETELY OBLITERATE
the points about strict static checking and this obliteration will continue
to become more important as applications grow larger and more dynamic and
more distributed.  Strong checking is wonderful where appropriate but in
many (if not most) cases it is simply not available; so sorry, wish it were.

[John says MI is poorly understood and still debated]

I simply disagree.  I fully understand everything about MI and there is
nothing contradictory, non-understood, difficult or inefficient about it
either in application or implementation.  Since this understanding
may not have been *so* prevalent years ago, I think you're listening to 
complaints from others who are about 5 to 10 years out of date.  MI
has no effect on any of the points previously discussed, the only
points worth mentioning are found in "fanatically" efficient languages
which optimize some of the functionality out of MI in the name of
radical efficiency and not because of straightforwardness or function
(which MI obviously provides).

The fat base interface problem occurs with virtuals (move all common
derived interfaces into the base) and has nothing to do with MI.

[On RTTI being a big deal]

I don't believe it is.  It is actually an extremely limited form of
dynamics and is trivial to implement.

[On Homomorphism]

Wonderful implicitly checked union idea.  Did it myself in school (and
without pointers or mess or unclean data, can you figure that one out?  [We
had little choice!-]  Tagged pointers still don't help with dynamics but
they're Ok with me.

[On the way C++ was intended to be used]

Have you checked with old Bjarne?  Or AT&T???  I've always had respect for
the telepathic abilities of others that can read designers' minds.  I love
it even more when these designers see such "mind-reading" and post to give
their real opinions!

[On downcasting as an "Almighty hack"]

A more structured (but less flexible) version is a typecase statement.
One might say to use messaging whenever a typecase isn't necessary, but
I'm not sure it should be considered as a hack.  Since I wouldn't want
to program in any language where some kind of even more powerful dynamics
than downcasting is either available or can be programmed (since then
my programs would be useless), I'm not sure about your feelings about
downcasting.  One might be able to get away with such strict (or strongly
statically typed) languages in more limited domains but this is certainly not
so in advanced applications.  Even the trivial GUI example requires them.

bob
objsys@netcom.com

P.S.  Have you ever wondered why your GUI is inflexible and nonextensible
  and has maintenance problems?  Its probably because its written with
  strong typing!  [Doesn't this make you feel more secure!?]

P.S.S.  What if my GUI has sound (and I've heard of a new one with smell,
  and what if I like touch too)?  Does that make it something like a
  "GSOHUI"???
Newsgroups: comp.object,comp.lang.functional