From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Need help implementic data structures of generic objects
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 16 Dec 1992 13:27:07 GMT

In article <1992Dec14.212143.15591@leland.Stanford.EDU> kocks@leland.Stanford.EDU (Peter Kocks) writes:
>My $0.02.  Use Obj-C.  I have just spent a fair amount of time comparing strong
>vs weak type casting systems (sometimes called static vs. dynamic binding) and
>have reached the following conclusions.  C++ is the optimum strong casting
>language, 

	I dont think so. It doesnt have preconditions, and they are a
crucial part of the type system. Eiffel does, so maybe it has
a stronger type system than C++ in this area.

	It doesnt have class invariants either, which are more
or less equivalent to preconditions if you construe the arguments
to a function as an object.

	It does have exception specifications though, also
somehow part of the type system.

>Smalltalk is the most popular weak casting system.  The ADVANTAGE
>of C++ is that it is strong casting (which makes the prevention of bugs
>considerably easier).  The ADVANTAGE of Smalltalk is that it is weak casting.

	Yes, precisely.

>The disadvantage of C++ is that when you want to do the more complex OOP
>techniques, they often make the most sense in a weak casting language.  

	Is the issue really about 'more complex' techniques?
Somehow I dont think this characterises the differences.

>C++ lets
>you get around the need for weak casting by giving you such things as
>templates.   Its not exactly the same, but it should enable you to implement
>your design.  

	Not quite, I think where templates are used nicely you definitely
DONT want the weak typing, if you did templates wouldnt work. So its
the other way around, when you want a homogenous collection in the
template-less language you cant have em, and you're forced to pay
the price in terms of correctness and efficiency.

>It also means that C++ gets much more complex as you increase the
>complexity of your OOP design.  The disadvantage of Smalltalk is that it can
>be slow.  

	IMHO the principle 'theoretical' disadvantage what you
mention below. That is the failure of the system to notify
you in advance of potential errors.

>
>Weak casting is a nice feature allowing you to send messages to objects without
>knowing how (or if) the message can be implemented by the object.  It really
>is great, but it makes for run-time errors which are bad (BUT not THAT bad). 

	I disagree vehmently :-)

	The *principal* advantage of C++ is that a whole class of
errors cannot occur in running programs. Namely those caught by the type
system.

	The problem in weakly typed systems is that there is no
way to ever really KNOW that the program doesnt have bugs,
I doubt even coverage analysis would be sufficient.

	In C++ you know.

>The solution, if you want a weakcasting system and you don't want to give
>up C, is clearly Obj-C.  

	I heard a rumor that GNU provides C++ and Obj-C 
togther in the one compiler?

>Unfortunately, we are stuck with C++ so the 
>ultimate answer I believe is to forget about doing any kind of weak casting
>design.  To do it in C++ is inviting disaster.  Smalltalk is not fast 
>enough (well maybe it is) and it does not give you C code possiblities.  Obj-C
>is the clear answer, but you'll be all alone.  
>
>I'm stuck with the same problem and I've decided to curse C++ and just
>get on with using templates etc...
>

	You are NOT stuck with 'C++', well not quite yet anyhow.
The standard is still being 'created'. I for one find the
dynamic loading ability of Obj-C interesting. I think this
will be mandatory in the future, the old idea of compiling
and linking a single standalone executable is just that,
old--obsolete.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++