Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!ncar!ames!lll-winken!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.lang.c++
Subject: Re: objective C
Message-ID: <3197@stpstn.UUCP>
Date: 2 May 89 17:32:44 GMT
References: <2614@ssc-vax.UUCP> <3180@stpstn.UUCP> <15327@gryphon.COM>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 65

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. At least as type or inheritance is defined
in programming languages, and ignoring for now other meanings that might be
appropriate in as-yet-uninvented specification languages, the type/inheritance
hierarchy is an implementation detail...that is, the business of the supplier
who implemented the receiving site. If the sending site is aware of and
exploits any information about the receiving site's type, a loss in flexibility
results.

Example:
	Programmer A is building a MailBox class, which must be able to 
	mail any kind of office object (whether existing now or in the future).
	He chooses to have MailBox inherit functionality from Collection, which
	inherits from Object. 

	Programmer B is building an Envelope class, which like MailBox must
	be able to contain any number of any kind of office Form. He chooses 
	to have Envelope inherit collection functionality from Collection.

	Programmer C is building a family of Form classes. For his own good
	and sufficient reasons, he chooses not to inherit functionality from
	Collection, but instead defiles an abstract Form class with separate
	subclasses for Memo, BusinessLetter, etc.

Programming languages that expect entities that must exhibit the same
external interface, such as the common interface that mailable entities
(Envelope and Memo) must provide to the MailBox, have trouble with this.
Reusability is so important that I was unwilling to compromise it in
any fashion, i.e. by making the binding mechanism aware of how a reusable
component was implemented (its type hierarchy).

Although we have since added C++-style 'dynamic' binding to Objective-C
as an option (in order to provide compile-time type-checking), our documents
describe it as 'static' binding to indicate that the compiler is aware
of the receiving element's type at compile time, and is therefore making
a flexibility tradeoff.