Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!texsun!texbell!sw1e!uucibg
From: uucibg@sw1e.UUCP (3929])
Newsgroups: comp.lang.c++
Subject: Re: Obj-C 'vs.' C++ with & w/out MI
Message-ID: <1572@sw1e.UUCP>
Date: 9 May 89 13:47:47 GMT
References: <2614@ssc-vax.UUCP> <3180@stpstn.UUCP> <15327@gryphon.COM> <1562@sw1e.UUCP> <176@mole-end.UUCP>
Reply-To: uucibg@sw1e.UUCP (Brian Gilstrap [5-3929])
Organization: Southwestern Bell Telephone Co
Lines: 133

In article <176@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes:
>C++ requires that if ``sprocket'' requests something of an object that has been
>passed to it, that object has been declared to have that capability (that
>member function must exist for the class of which the object is an instance).
...
>The programmer of ``sprocket'' must declare what he will accept, and the
>things that he (or his class) will accept must have a set of capabilities
>(member functions) which includes all that will be asked of them.

But in Objective-C, you can check these sorts of things at runtime if you
want.  You can do one of several things:

(A) be rigid and decide that inappropriate objects passed to your object mean
your program barfs out.  This might seem like an unacceptable choice.  But
note that you can redefine the 'error' method.  This error method is invoked
whenever the message resolution routine discovers that you're trying to
send an unsupported message to an object.  Thus, you could redefine (override)
the error method to do a gracefull shutdown.  If this sort of approach is
considered horrible, then look at all the programs that do it for things like
file size limitations, not enough memory (Bison), something went screwy. 
Thus, 'it bombs if you missed a bug' is no more true than for a normal
C program and is in fact significantly more robust than for normal C or C++.
This, I believe, is one of the big reasons behind the interest in exception
handling for C++.  Don't get me wrong, this isn't full exception handling, but
it helps.

(B) do runtime checks to make sure that the object passed responds to the
message you want to send.  This involves the use of the 'respondsTo' message.
This allows you to find out if object foo responds to an arbitrary message.
This is particularly usefull if you want to allow varying degrees of support
for a message protocol (sure I'll allow object's which can't be
'realtimeDisplay'-ed but only if they are at least 'display'-able, since they
are in essence real-time displayable: they just don't change over time).

(C) (with vsn 4.0 of Stepstone's compiler) you can prototype without
type-checking and then turn on type-checking when it gets to production code.
This amounts to Smalltalk-like prototyping (without the nice browser <yet?>)
but with production code a la virtual functions in C++.  Now, if they would
just add MI and non-virtual functions for classes... :-) (of course, runtime
MI message resolution in a Smalltalk-like world can get prohibitively 
expensive very quickly I should think).

I wrote:
>> ... This means that the person writing the code for the supplier must decide
>> a priori what tasks 'sprocket' might be usefull in solving.  But the whole
>> point of writing suppliers it to avoid making decisions about what kinds of
>> problems can be solved with code for 'sprocket' and instead let the client
>> programmer look at available classes and decide what to use.

Mark responded:
>This is getting pretty close to one of the uses of Multiple Inheritance.
>If I have a Doojigger which I want processed by a Sprocket, then Doojigger
>has to somehow inherit the capabilities that Sprocket will use.  If it
>doesn't, I'm free (using MI) to quickly wrap a derived class around Doojigger
>recasting the operations that are needed into those that are available.
...
>This means I have to do a little work.  In return, I am guaranteed that I won't
>get a runtime error from the method dispatch system.  In code that I am
>building into a product, I think the tradeoff is appropriate.
...
>It also means that the Sprocket must get its ``print'' from a visible, if
>not standard, set of declarations.  The first part is easy; the second is
>significantly harder.  .......

I agree wholeheartedly with this.

>.....................  It's less of a problem in a large project that has
>its own standard environment or in a case where you've bought a complete
>bunch of goodies from one software author/vendor.

True.  This is one that I'm still thinking on.  However, it would seem that
there would need to be certain standards (ack! yet more) regarding the format
of classes and their documentation.  Just as in the hardware world, not every
'sprocket' would be compatible with every 'cog' (TTL, ECL, CMOS, etc?).
However, just as in the hardware world, things can be tweaked.

I wrote:
>> ...  Furthermore, the 'precompiled classes' scenario prevents this option
>> anyway since you can't control the inheritance tree of the precompiled
>> classes you (theoretically) buy from some software vendor.  ...  This
>> severely limits the reusability of the code for 'sprocket'.

Mark said:
>Again, MI does provide a solution.

Very true.  I don't have enough experience with MI to know how much it overlaps
with weak-typing in terms of solving the same set of problems (as discussed
above).  I'm working on this knowledge.

>I'm not so worried about software re-use.
Then I think that in some sense we're tugging at different ends of the
OO-towel :-).  Not totally, but to at least some degree.

>There are also two ways to view OOP.  One is to view it as a way to build
>programs from existing pieces; the other is to view it as a way to organize
>the structure of a problem so that a well-structured program may be written.
...
>Both approaches have their place, but on the large scale, I think that the
>latter is the way to get programs for which the efforts of ``testers''
>... will more rapidly
>converge on a program which for which liability can be risked when it is
>placed in the hands of thousands of customers.

Hmmm, why do you make this assertion?

Mark writes: [in regard to strong-versus-weak typing]
>.....  Getting it right in concept and reliable in fact are more important to
>me.  A program that is not reliable is a legal, ethical, and moral liability;
>if it's so unrealiable that it has to be tweaked over hundreds of times because
>it was put together from the parts that were there, rather than built from
>parts whose correct relationship to each other was established, it's a
>financial liability as well.  Those finances finance our paychecks.

So you wish to depend upon the compiler to assure that the types of the
arguments are correct.  Personally, I consider this to be about 5% of the
'relationship verification' process.  I don't think I buy this one.

>Oh, and if the C++ templates can be implemented (3.0 ?) they will probably
>improve the situation still further.

But only if you have all source code available.  This kills the 'cogs
and sprockets from a vendor' idea.  That's like every computer manufacturer
being forced to build their own chip manufacturing facility for 80+% of
their chips (and many of the rest of the components too).

>(This man's opinions are his own.)
>From mole-end				Mark Terribile

Brian R. Gilstrap                          Southwestern Bell Telephone
One Bell Center Rm 17-G-4                  ...!ames!killer!texbell!sw1e!uucibg
St. Louis, MO 63101                        ...!bellcore!texbell!sw1e!uucibg
(314) 235-3929                             ...!uunet!swbatl!sw1e!uucibg
#include <std_disclaimers.h>