Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!servio!riks
From: riks@servio.UUCP (Rik Smoody)
Newsgroups: comp.object
Subject: Re: Do we really need types in OOPL's?
Message-ID: <698@servio.UUCP>
Date: 21 Sep 90 19:57:55 GMT
References: <0yw10qr@Unify.Com> <275@sps.com>
Reply-To: riks@servio.UUCP (Rik Fischer Smoody)
Organization: Servio Logic Development Corp.; Beaverton, OR
Lines: 70

In article <275@sps.com> wwb@sps.com (Bud Bach) writes:
>In article <0yw10qr@Unify.Com>, dbrus.Unify.Com.brian@unify.uucp (Brian Meyerpeter ) writes:
...
>There's the rub.  In large systems it is difficult to remember or "know"
>the interface.  If an object is typed then, the client has some 
>confidence that the object will plug into the system and respond to 
>the appropriate messages.  
>
>Also don't forget that objects may be passed as parameters or returned
>as functions also.  As an implemeter of a class, it is useful to
>restrict the kind of objects that may be passed to some useful subset.
>For example, suppose you wish to export a method for adding the
>contents of a container to another container.  What if the client
>sends an integer instead of a container?  Granted, you might catch
>this at runtime, but why not catch it sooner?
If "type" is confused with "isKindOf: someClass", then too often it is just not the right question.
Your container example is fine: somewhere in the system should be recorded what you mean
by "container".  If I have an object which I assert qualifies, how can we tell? 
Let's encapsulate the questions.

In the predestination model (where God created the world at compile time
and everything was deterministic after that), that information is somehow compiled in.
If inheritance is used, and the type information is (mis-)mapped onto class membership,
only a new class which IS a subclass of the chosen class is admissable.

Instead, I think we need to treat the Protocol itself as a first-class object.
Then it is easy enough to ask questions such as
	"Does my class named Pocket obey the Protocol known as #Container?".
		(The details would obviously verify that it could respond to #size, #do:, #at:, etc.
		The set of questions is stored in the Protocol)
If so, then I should be able to pass a Pocket full of things to your container...
even if God (or whoever beat on the system before the Big Bang) did not imagine Pocket.

Furthermore (not my recommendation, just an observation), an inheritance system
typically allows a user defined subclass to BREAK the (unmanaged) protocol
of a superclass.  E.g. if I created Bucket, subclass of Container, but overwrote
#do: such that it is not compatible with the normal expectation of #do:, then
even though a type-checking system would allow a Bucket, it would NOT work.

> In large systems it is difficult to remember or "know" the interface.
All the more important that a computer help us remember.
If there's a rule that must be obeyed by some parameter, I want to be able to
ask my development environment to tell me exactly what I need to know...
and I want it NOW, while I'm working on the problem, not an hour down
the road when some compiler tells me about a type mismatch.


> Why not catch it sooner?
I'll go along with that: catch errors where it is easiest or
most efficient (your choice) to do so, as long as you don't expect to
catch problems *before* they are defined.  In systems with frequent Big Bangs, you
can talk about deciding a lot of things at "compile time".
But in systems comprised of objects, rebuilding the
universe each time a new kind of thing comes along is just too expensive.
Instead we should be able to adjust dynamically.  It is possible for cooperating objects
to establish contracts such as "only send this message with an argument that obeys #Container".
A client agrees to the terms (for example, it sends an instance
variable which is constrained to obey #Container, or puts a single thing into a box for shipping)
so no effort is wasted on redundant checks.

There is really little difference in the kind of checking and contracts that can be formed,
but there is a big difference in flexibility of when they are formed.
Sometimes it is important to ask just the right question at the right time.

Let's not feel bad if it's not immediately obvious: even my favorite
OO environment (the Earth) is not perfect.  People sometimes ask the
wrong questions at the wrong times.  (oh what a lovely tangent to digress along  8-)

Rik Fischer Smoody			Some people at Servio might agree with me
riks@servio.slc.com	Ph: 503-690-3615	Fax: 629-8556