Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!tektronix!sequent!archiel!archiel
From: archiel@mntgfx.mentor.com (Archie Lachner)
Newsgroups: comp.lang.c++
Subject: Re: objective C
Message-ID: <1989May4.163906.6814@mntgfx.mentor.com>
Date: 4 May 89 23:39:05 GMT
References: <3197@stpstn.UUCP>
Organization: Mentor Graphics Corporation, Beaverton Oregon
Lines: 49

From article <3197@stpstn.UUCP>, by cox@stpstn.UUCP (Brad Cox):
> In article <15327@gryphon.COM> sarima@gryphon.COM (Stan Friesen) writes:
>>In article <3180@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes:
>>>
>>>The short answer is that C++
>>>relies on static binding and strong type-checking, while reusing code
>>>involves binding a supplier's code with a consumer's code long after
>>>the supplier's code has been compiled (and therefore bound to whatever
>>>types the supplier knew about at the time...which fails to include the
>>>consumers').  For the longer answer, read the book
>>>again...closely...and try working the examples in C++.
>>
>>	This seems to be a common mistake of less intensive C++ programmers.
>>C++ does not *rely* on static binding, it *permits*, or perhaps *encourages*
>>it, but definitely not rely!   Dynamic binding in trivially available, it is
>>called "virtual functions".   Of course since all "functions/messages" are
>>"virtual" in ObjC, attempting to code any ObjC class that relies on library
>>classes in C++ would require writing the associated library using virtual
>>functions.  But I do not see any other problem that would prevent the
>>example from being done in C++.  Admittedly, ObjC is more advanced in its
>>standard library of predefined classes, but that is its only real advantage
>>over C++.
> 
> When I initially designed Objective-C, my first thought was to make its binding
> mechanism work like C++'s virtual functions; e.g. so that the sending site 
> knows and enforces the type of the receiving site at compile time, but with
> a dynamic dispatch (ala C++'s virtual function dispatch via the VTBL) to
> allow the receiving site to have siblings.
> 
> I rejected this approach in favor of Smalltalk's binding style, in which the
> compiler does not know or enforce any restriction on the type of the receiving
> site, for the following reason. ...

So C++ does have the ability to reuse code by binding a supplier's code with a
consumer's code long after the the suppliers code has been compiled.  It just
does so in a type-safe manner (all of the consumer's types must be the same as
the supplier's or derived from them).  The supplier's code can then deal with
the consumer's types, and in a constrained but safe manner.

Your original posting did not indicate this, but quite the contrary lead some
people to believe otherwise.

You're right.  This is different than Small Talk and Objective C.  Whether
the Small-Talk approach is "better" is debatable.
-- 
Archie Lachner
Mentor Graphics Corporation
Beaverton, Oregon
...!{decwrl,sequent,tessi}!mntgfx!archiel