Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.lang.c++
Subject: Re: objective C
Summary: What the @#$^% does OO MEAN anymore?
Message-ID: <3180@stpstn.UUCP>
Date: 22 Apr 89 19:26:02 GMT
References: <2614@ssc-vax.UUCP>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 75

In article <2614@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes:
>  I, as I've posted previously, am interested in
>comparisons between C++ and other OO languages.  Could
>you please provide some substance behind the argument
>that C++ is OO and ObjC is not?
>
>  I've read a great deal of Brad Cox's book "Object Oriented Programming,
>An Evolutionary Approach".  In the book, Brad talks at some length
>about C++, and how it implements OOP, and he *seems* to imply
>that building software IC's is easily done in ObjC, but either
>not possible, or difficult to do in C++.  Anybody have any light
>to shed on this?  Brad are you there??

Sorry I'm late in responding to your article. I monitor this network
very irregularly these days.

Although I'm gratified at the recent surge of interest in OO, I find
that I am unable to defend any sharply-defined boundary to this term,
apart from the precisely-stated but arbitrarily-chosen ones. OO is a
loosely-defined adjective, exactly like other adjectives that all of us
use daily ('big' or 'high-level' or 'good'), without obsessive worrying
about where gray shades into black or white.

I find a number of such such arbitrarily-chosen definitions are useful
depending on the situation at hand. For example, In my first book, I
used an obsessively narrow one by merely defining terms like 'object'
and 'message' directly in terms of a specific programming language, and
thereby excluding every other claimant to the OO title, not only Ada
and C++, but also even newer implementations of the Objective-C
language such as the Objective-C interpreter.

However we can also obtain valuable insights by holding our obsession
with technical precision in check (just as we do with other adjectives
like 'big') and searching for commonalities between EVERY claimant to
the term. What does Objective-C and C++ and Ada and MacDraw and
MetaphorGraphics and Fabrik and OODesign and OODatabases and
OOUserInterfaces and OOWhatEver all share in common?

The commonality that I see there is that all of these approaches share
in the belief that the software domain, which is really a hybrid
between the concrete world of tangible THINGS and the abstract world of
intangible IDEAS, can be understood more readily by looking at it first
from the perspective of the concrete world of tangible things; i.e.
OBJECTS, and then treating the influences from its intangible heritage
as second-order perturbations.

Notice that this definition brings all kinds of strange creatures
inside the boundary (all of Software Engineering', for example, because
of their interest in applying engineering principles that apply to
tangible things to this hybrid stuff, software).

However this broader definition does exclude major branches of our
community as well; that segment that prefers to view software primarily
as IDEAS and secondarily as THINGS. For example it excludes most of
what I think of as computer science; those who conconcentrate on
algorithms as opposed to programs, and particularly those (CAR Hoare
comes quickly to mind) who prefer to treat software as if it were a
mathematical entity first and an engineered object second.

So to boil all of this down to brass tacks, I don't feel that it is
useful to say any given programming language is OO or not, because any
boundary is arbitrary. I used C as an OO language during most of my
career, and developed Objective-C to automate things that were too hard
to do (and to teach to others) that I'd long done by hand.

Of course, none of this answered your real question...why highly
reusable software (Software-ICs is a trademark...it applies STRICTLY to
Objective-C, by law) is harder  in C++ (never impossible...remember I
used to do this stuff in raw C too).  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++.