Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!ucbvax!agate!shelby!portia!Jessica!duggie
From: duggie@Jessica.stanford.edu (Doug Felt)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Comments on THINK C 4.0
Message-ID: <4590@portia.Stanford.EDU>
Date: 17 Aug 89 16:52:12 GMT
References: <10362@fluke.COM> <227700029@uxa.cso.uiuc.edu>
Sender: USENET News System 
Reply-To: duggie@Jessica.UUCP (Doug Felt)
Organization: Stanford University
Lines: 52

In article <227700029@uxa.cso.uiuc.edu> jpd00964@uxa.cso.uiuc.edu writes:
>
>/* Written  3:42 pm  Aug 14, 1989 by mce@tc.fluke.COM in uxa.cso.uiuc.edu:comp.sys.mac.programmer */
>/* ---------- "Comments on THINK C 4.0" ---------- */
>> Some quick initial comments:
>>	2) The new() operator does no type checking.  You would like for
>>
>>		CMyApplication gMyApplication;
>>		...
>>		gMyApplication = new(CApplication);
>>
>>	   to cause a compiler error, but it doesn't (this type of error can
>>	   be a good way to crash your machine). 
>
>You do not want the new operator to do type checking like that.  It should 
>be extremely easy to allow different objects to be assigned any variable.
>For example, assume an object called holder.  Subtypes of Holder can be cup,
>box, sack, etc.  Each of these have identically named routines that act
>differently.  You should easily be able to have one variable that could be
>any of those.

Actually, you don't want to assign an object to a variable whose type
is one of its subclasses, which is what the original example showed.
You would be tempted to access fields of the object variable that didn't
exist (assuming one has access in Think C 4.0), or call methods that
weren't implemented for that object.  

Your (implied) counterexample is not a true one, because to do what
you describe, one assigns an object to a variable whose type is one of
the object's superclasses.  Accesses through this variable will always
be valid, as the fields and methods of the superclass are always
defined in the subclass.

I believe Object Pascal restricts assignments in one direction but not
the other.  I am not sure but I think the assignment is a runtime
restriction, in that code is generated to check the class of the
object being assigned and test this against the class of the variable.
Thus 'new' is not doing the work, and the restriction applies no matter
where the object came from.

Perhaps the reason this restriction wasn't implemented is because it
was doubly damned, as being both a runtime penalty and a crutch for
programmers who can't handle C.  Me, I prefer all the assistance the
compiler can give me, but a lot of C programmers are proud of having 
learned to live on the edge... :-)

>Michael Rutman
>Softmed

Doug Felt
Courseware Authoring Tools Project
duggie@jessica.stanford.edu