From: dnavas@oracle.uucp (David Navas)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Obj-C vs. C++ [was Re: Comeau C++]
Date: 30 Sep 92 16:44:48 GMT
Organization: Oracle Corporation, Redwood Shores CA
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <jac.717747506@moonshine> jac@moonshine.llnl.gov (James A. Crotinger) writes:
>dnavas@oracle.uucp (David Navas) writes:
>> C++, it seems to me, was designed to provide an object-oriented >interface<
>> to C, where Obj-C was designed as an object-oriented language with similar
>> syntax as C.
>  I guess this is a matter of opinion. Obj-C always looked like someone
>tried to graft small-talk on top of C. C++ seems more C-like, and if you
>like C syntax (I do), it seems more elegant.

Yes, this is a matter of opinion.  But remember that this all started with the
claim that Obj-C was closer in Zen to Boopsi than C++ was, in part because
Boopsi was based on smalltalk.  [Correct me if I'm wrong, Stefan]

And, of course, we're really saying the same thing.  C++ is C with an
object-oriented interface, Obj-C is smalltalk with a C interface.  We've
both just said that (basically)!

>
>> I'm not sure how stringent Obj-C type-checking is, but it's worth
>> noting that if your methods are bound at run-time, it'd be rather
>> difficult to type-check them at compile time....

>  This is not true. C++ does have run-time binding, and it is type-safe.

C++'s run-time binding is only valid when the objects concerned have a
common subclass.  In this case, type-checking is possible.  However,
requiring both type-checking AND common subclasses (even noting that
C++ has multiple inheritence) is a rather large impediment to creating
system subclassable class definitions.

With SHADOW I can create a selector without ever declaring what classes
it may or may not belong to, or even what arguments it may or may not
take.  I'm not sure how C++ handles default argument differences with
virtual functions -- if it does, it's doing quite a bit of work, if it
doesn't, then it's basically useless for what I need to get done.

>Suppose class D inherits from B, which declares a "virtual function" 
>named "foo". Class D can provide its own definition of "foo". Now,

And to call D's superclass' definition of foo we'd just type-cast right?
So what happens if D shifts within the hierarchy?

>This is all type safe! The compiler has seen the declarations of
>B and D. It knows that the B class understands the message "foo",
>and that any class which publicly inherits from B will also understand
>this message.

Yes, but it understands the message only in that the message must be
exactly equivalent.  This is not always true in real life.
Consider the OpenWIndow() calls in Intuition.  We have OpenWindowTags()
and OpenWindow() which are two separate definitions of the same selector --
OPEN_WINDOW.  Depending on the class (V1.3 or V2.0) you're sending the
message to, different arguments are required.  How do you type-check in
cases like this?

>What C++ won't let you do is to send a message to an object which
>the compiler doesn't know anything about. For example, suppose D

Right.

>My understanding is that Objective C will allow something like this.

That's my understanding as well.  Sort of hard to find a definitive book
on recent implementations of Obj-C compilers, though.

>However, what would happen if pb pointed to a B? This is not a safe
>program. You might say that you'd only do this if you knew that pb
>pointed to a D. Well, if you do know this then you can cast the pb to

Nope, you've confined yourself to working within C++ too long, and are
using an argument which rationalizes the way C++ works. :)

If pb pointed to a B, then the message would be ignored as it isn't
impemented.  This kind of behaviour is sometimes used for callbacks.

Now, in C++ you could change the definition of B to support this as well --
if you have appropriate access to the source.  Think Cmdre would give out its
OS source?  Nah, didn't think so.

>I can think of is that it might be somehow possible to "dynamically
>link" new messages into a running program, and then send these
>messages to existing objects. Is this possible? Do you have any other
>examples?

I don't know if you can do this in Obj-C.  Under SHADOW it would be possible
(difficult).  I concentrated more on creating message-patches rather than
new message additions.  New messages are dealt with by subclassing, no? :)

Well, you could create code that worked for all base classes, but which
sent messages to objects that are only implemented under your new subclass
scheme (as described above).  Without the need for the original source or
definition of the base classes.

How difficult is it to have C++ create objects in, say, CHIP_MEM?  Or
allocate objects from a private memory pool?

It might not be a bad idea to attend Taligent's meeting (sometime in early
October).  They had to dump C++ (they have some bizarre notion about creating
their own object-oriented C derivative last I heard) for some reason.  It
might be interesting to get their perspective....

>> At the same time, I don't understand how you can possibly claim that
>> an object-oriented language is polymorphic when methods are bound at
>> compile-time.
>  See the above. C++ is polymorphic.

Yes, but not for early binding methods :) :).  Which, of course, is what
I really said.  I assume we're making a distinction between overloading and
polymorphism as well....

>> Depends.  Again, remember that there are competing design goals.
>> C++ produces code that is -essentially- not object-oriented, but it
>> is created in an environment that is [God, I feel the flames
>> already, why do I make such wild generalizations?]. n

>  I do agree that polymorphism is an absolute necessary feature of an
>"object oriented" language; however, as explained above, C++ has this
>feature.  Perhaps after reading my above explaination, you'd like to
>reconsider this statement.

Probably not.  One of the advantages of object-oriented code is the
layer it creates between implementation and calling mechanisms.  I'm
not so sure that layer is real thick if I need to go and rehack base classes
just to provide some polymorphic messages I need for subclasses.  In
additions, it would be nice to only have to ship -partial- definitions
of structures to the end-programmer -- ie: only the parts that they
can read or read/write.  While public/private is a really nice feature,
it gives away a little too much of the "magic" for my tastes....

>You can write completely object oriented code in C++!

Very true!
I think my claim is that it's not always the best tool for the job --
which ought to have been self-evident (~truism).  Not that anything was
"impossible", which is an invalid argument for any "Turing-complete"
language (assuming it's possible in the first place ;)).

David C. Navas						dnavas@oracle.com
Working for, but not speaking on behalf of, Oracle Corp.
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware