Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: Objective C: Flame Fodder
Message-ID: <6590116@hplsla.HP.COM>
Date: 8 May 89 16:15:17 GMT
References: <5007@tekgvs.LABS.TEK.COM>
Organization: HP Lake Stevens, WA
Lines: 61

Regards Brian's comments on the 'virtues' of not 
type checking:

When I was programming in ObjC, I found the lack of
type checking to be a curse, rather than a blessing.

I'd write a class with a method say 'doSomething:'
that takes an int parameter and returns a double
result, and someone else would quite unbeknownst
to me accidentally write a method also called
'doSomething:' taking an id as a parameter and
returning an int, and all of a sudden my compiles
would stop working.  Ouch!  And then you'd spend
a day running around the lab trying to find out
who writing what class came up with a method
name returning a different type than your method.

Eventually, to get around these problems, many
programmers took to writing method and object names like:

aCertainClass objectOfaCertainClass;

anInt =[objectOfaCertainClass certainClassMethodreturningInttakinganId: anOtherObject]

-- Well I exxxagerate, but the point being, without overloading and disambiguizing
names based on parameter types, people were forced to come up with deliberately
weird and ugly method names in order to avoid conflicting accidentally with
someone elses names.

Maybe in Smalltalk, where everything really is an object, this would be
less of a pain.  But it ObjC, where primitives (int, char, double, float, etc)
have a type and composites don't have a type, you were forced to do weird
name encoding to avoid conflicts.

Of course, cfront just does all these weird name encodings for you, automatically!
:-)  But at least only the linker has to look at the weird names, not you or 
your fellow programmers.

I think Brian's complaints have some merit in the absence of multiple
inheritence.  But with multiple inheritence you can easily add the compatibility
necessary to use your classes with someone else's classes.  Only when there
are direct method name conflicts would extra effort have to into resolving the
conflict. [Not hard -- just requires writing a method.]  More importantly,
with multiple inheritence each and every class is NOT forced to have  
a certain collection of a couple dozen basic methods -- and the underlying
store requirements in each object that those methods imply.

So a complex number in C++ can consist solely of two doubles -- if you
want to use a complex number in JoBlow's whizbang object class hierarchy
scheme, you can glue Jo's stuff to the complex stuff using multiple
inheritence -- you are not forced to buy into Jo's scheme from day
one and for all eternity.

So for example, I'm not totally enamored with streams, so sometimes I
don't use them.....

I'm not crazy about Gorlan's approach, so sometimes I don't use his
stuff -- other times I use them...

In C++ you get the choice, the control over what software you write,
and what software you use.