Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!mas1!hawley
From: hawley@mas1.UUCP (Ken Hawley)
Newsgroups: comp.lang.misc,comp.lang.smalltalk,comp.lang.c++
Subject: Re: C++ vs Objective-C
Message-ID: <980@mas1.UUCP>
Date: Thu, 19-Nov-87 16:24:46 EST
Article-I.D.: mas1.980
Posted: Thu Nov 19 16:24:46 1987
Date-Received: Sun, 22-Nov-87 03:03:48 EST
Distribution: na
Organization: Measurex Automation Systems, Cupertino, CA
Lines: 40
Keywords: Dynamic Binding or Not
Xref: mnetor comp.lang.misc:904 comp.lang.smalltalk:431 comp.lang.c++:593

>In article <1662@ppi.UUCP> cox@ppi.UUCP (Brad Cox) writes:
>>For example,
>>consider the different kinds of problems in building an automobile.
>> . . .

To which Mr. Adams of Multimate International says, in part:

> . . .       Objective-C
>forces you to give up type checking entirely for cases where you want any
>dynamic binding.

This comment is relevant only if you choose to build you system in a way
that makes dynamic binding important, i.e. using extensive sub-classing.

If you are building an end user system, you can sub-class to your heart's
content.  However, if you are building a GENERIC PRODUCT, then there are
serious shortcomings to the extensive use of sub-classing.

The alternative is to use a small number of generic objects together with
(what Cox has called) property lists to configure or "parameterize" those
objects for a particular application.  Voila!  Dynamic binding without the
binding!  You don't get type checking either, but you have gained something
much more valuable:  a generic application.

To go back to Cox's example:  consider the automobile assembly.  You could
have a wheel object, a vehicle object, an engine object, a trunk object, etc.
Or you could have one, "assembly" object which takes on the properties of a
wheel, a vehicle, an engine, or a trunk depending upon how it's configured.
In the first case, if you change the engine, you must change the class.  In
the second case, you merely change the property list.

Remember why we use object techniques:  (1)data hiding, (2)reusability,
(3)explicit modelling of physical systems, (4)distributability, (5)scalability.

Inheritance is a MEANS, actually only one means, to achieve these objectives
in an object environment.  It is not an END in itself.

-- 
Kenneth J. Hawley   (hawley@mas1)      Measurex Automation Systems
{...}pyramid!voder!mas1!hawley         Cupertino, CA / Detroit, MI
{...}codas!mas1!hawley                 (408)973-1800  (313)271-0333