From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 12 Oct 1992 19:28:51 GMT

In article <1992Oct11.002200.20515@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
>[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.  

	This sound contradictory. If you add a totally new class, 
no existing program could possibly interface to it. If the new class
can be manipulated by existing code in some way, there must
already be an interface with which to do the manipulation declared,
and you can derive that new class from that interface.

>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.  

	No, I wont. Given I want a static system I would start
with GUI classes that describe the various components that 
the GUI system can handle. I would be restricted to deriving
new classes from these old ones, the GUI could not manipulate
them otherwise. Of course I can have my own functionality
which naturally only *I* can sensibly use.

	I program Windows. I have my own types of window,
with special functions. There is in fact a base class
Window with a single function 'execute(msg)'. My system
is completely static (it is C++ so it has to be).

>If you want to add new classes and objects, statics
>alone can't handle it.  

	I dont agree, I had no such problem adding new Window
types in Windows. It is admittedly not a fantastic system,
and I had to cheat here and there because it is not object
oriented and has a foreign interface (Pascal calling conventions
actually)

>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.  

	A poorly designed GUI might well impose constraints on you
that downcasting could help with.

>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.

	I do this all the time. Naturally, no one but me can 
possible use the new method, because I just invented it.
I have no problem using it (because I'm always 'in' my exact
object when the 'execute' method is invoked).
>
>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!

	This is true in say Smalltalk--it cannot do otherwise.
That you believe there are not alternative methods in static systems
does not mean this is the case. It is certainly true that
foreign interfacing can benefit from dynamics, if only because
the foreign interface has been poorly designed and cannot
accommodate proper static design. For example Windows
allows a long integer to be stored in a window, and I have to
grab it and cast it to a pointer to call my 'execute' function.

	However, even if everything is derived from 'GUI_Base'
which has only 1 function, 'execute', you can discover the type
as it were by simply calling 'execute'. Control is then
transfered into a scope with full static knowledge of the exact
type of the object.
>
>And these environments require some form of dynamics, there is no way
>around it.  

	Why have I not had this problem in Windows?

>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.

	Well, again, please tell Borland their ObjectWindows cannot
work because you say so. Yet it uses C++ which is static. 
It has some kludges, I dont use it myself.

>
>[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.  

	Oh. Well, in that case I have some questions for you. Please
post the answer to comp.std.c++ because no-one else knows the answers
to some of these questions, including Bjarne and some of the
academics I have talked to.

	1) What is the correct method for initialising virtual base 
	classes?

	2) Can MI be simulated by SI? Can you give an example where
	MI is essential?

	3) What is the correct way to factor classes into small
	independent classes suitable for recombination using MI?

	4) When you derive classes you make subtypes (sometimes,
	anyhow), how do you create a 'superclass' of a base class?

	5) Explain how to redesign C++ so multiple calls of virtual
	function bodies of virtual bases will not occur when you	
	want to 'chain' down to the base functions.

	6) Explain why no book has been written espousing the virtues
	of the 'mixin' style enabled by abstract virtual bases using
	sibling calls. Not even Coplien mentioned it.

	7) Ill post more as I think of them. Anyone else?

>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, 

	I disagree. It has considerable impact on the 'fat interfaces'
issue. You spoke above of moving virtuals to *the* base class,
why did you not mention having multiple base classes, even adding new
ones for the new functions?

>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).

	There is a fairly recent article challenging anyone to
show MI is useful, no one has done so, nor a single example
given that could not essentially be done using SI. 
>
>The fat base interface problem occurs with virtuals (move all common
>derived interfaces into the base) and has nothing to do with MI.
			 ***

	YES it has. 
>
>[On RTTI being a big deal]
>
>I don't believe it is.  It is actually an extremely limited form of
>dynamics (Yes, it is, perhaps too limited considering the potential
damage it does. If we're going to add dynamics, why not implement
something substantial?)
and is trivial to implement.

	Even across process boundaries? Across networks?
Across foreign interfaces? Into OODBMS servers?

	But it is these types of cases where it is hardest to
implement (if possible) that is where you might need it.
>
>[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?  

	Yes, I have as a matter of fact.

>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!

	Just go and read the section of sibling calls in the ARM
and try to figure out how tremendously powerful this mechanism is. 
I lamented the fact that it is so poorly understood that
several of the MAJOR compilers (including AT&T's !) rendered
the use of this facility impossible due to a misinterpretation
of the ARM definition of Abstract Classes. 
>
>[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.  

	Its a hack in the sense it is used to regain lost information.
You create an object and forget its type so you downcast to jog
your memory. Why did you forget the type in the first place?

>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.

	Alternatively, any system you think requires dynamism is by
definition 'advanced'.

	Nothing precludes my using a static system to implement
dynamism of my own form. C++ does have pointer variables.
>
>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!?]

	But it isnt. Windows is completely user extensible.
It has no 'maintenance problems' (only design flaws). Old
programs running with Windows 3.0 run perfectly well with
Windows 3.1 without recompilation or relinkage.

>
>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"???


	Is that like raw fish?


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Xref: sparky comp.object:3893 comp.lang.functional:1234