Xref: utzoo comp.object:1574 comp.lang.c++:8904
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!asylum!osc!tma
From: tma@osc.COM (Tim Atkins)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Choice of language for manufacturing Applications
Message-ID: <3228@osc.COM>
Date: 9 Aug 90 09:00:18 GMT
References: <26686@pasteur.Berkeley.EDU> <56343@microsoft.UUCP>
Reply-To: tma@osc.UUCP (Tim Atkins)
Followup-To: comp.object
Organization: Object Sciences Corp., Menlo Park, CA
Lines: 41

There seems to be some confusion on the differences in binding strategies
employed in C++ (and other strongly typed languages) as compared to those
employed by Objective-C (and other untyped or less strongly typed languages).

In C++ the type of all objects must be known at compile time.  In the case
of a pointer to the object the actual type of the object at run-time may
be any subclass of the specified type.  The virtual method of binding starts
with the assumption of a known base.  The actual code generated takes advantage
of this knowledge to do a relative lookup of the function to invoke in relation
to this type information and the actual type (indirectly speaking) of the 
object.  The "indirectly" is due to C++ not really keeping run-time type info
at all but only building indirection tables in fixed locations of the object
layout to accomplish the binding.

In Objective-C and Smalltalk the binding occurs by looking in tables maintained
by the class structure/object corresponding to the object.  Every object
contains a pointer to its class.  Thus type 
information is available at run-time and the lookup of a method is based 
solely on the run-time type and the message selector.

This difference is a two-edged sword.  Objective-C makes possible the 
"message not understood" form of error at run-time although code checks can
be put in to ameliorate any problems due to this possibility.  Having type
information at run-time is a separate issue but I have personally found it
useful to add this to C++ environments as have many other users.  The true
dynamic binding ability of Objective-C makes possible much more flexible reuse
of software as less of the future scope of the need for such reuse had to be
known and prepared for ahead of time.  This form of binding technology
allows a much higher degree of polymorphism. 

It also makes possible very powerful techniques such as the perform: method 
allowing any message, even one composed at run-time, to be sent to any object.  
In its current incarnation I know of no way to do such a thing in a tractable 
fashion using C++.  This capability is of more than academic interest as it 
is extremely useful for building "proxy" objects that forward messages to the 
real object which may be on disk or another machine at the time.  While there 
are ways to do proxy-like classes in C++ they are not nearly as general or 
clean.  

I personally believe that C++ would be a more robust language if it included 
this type of late binding as an option.