Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!apple!portal!cup.portal.com!Invader
From: Invader@cup.portal.com (Michael K Donegan)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Casting in Think C
Message-ID: <36653@cup.portal.com>
Date: 7 Dec 90 16:40:23 GMT
References: <6167@munnari.oz.au> <3028@skye.cs.ed.ac.uk> <40@bootsie.UUCP>
  <41@bootsie.UUCP>
Organization: The Portal System (TM)
Lines: 27

This is the major difference between an interpreted language like
Smalltalk and a compiled one like C++ or Think C.  In Smalltalk,
you can send any message to any object.  If that object does not
understand the message, an error occurs.

This lack of type checking is inconvenient, but can also have
some nice results.  In Smalltalk, the notion of type is much
more flexible: in a given context, an object is the right type
if it handles the messages sent to it and satisfies the semantics
expected of those messages.

Given this notion of type, you can make an object masquerade as another
object by supplying the right methods.  This can't be done in Think C
unless both classes have a common base class that has the same methods
and we have declared our object to be of the common base class.

So, for example, in Smalltalk, there are Stream's that can be read
from using methods like 'next' to fetch the next thing in the stream
and 'atEnd' to test if the stream is exhausted.  I could create a
new class and use it in some context as a Stream, if I supply the
two methods.  My new class does not have to be a subclass of
Stream.

But then, Smalltalk is a lot slower than C++ or Think C, so we
just have to pay the price of this loss of generality.  It would
be nice if we could have both, though.
	mkd