Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!ceres.physics.uiowa.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: johnson@m.cs.uiuc.edu
Newsgroups: comp.object
Subject: Re: Void references
Message-ID: <77500064@m.cs.uiuc.edu>
Date: 11 Nov 90 01:55:00 GMT
References: <447@eiffel.UUCP>
Lines: 66
Nf-ID: #R:eiffel.UUCP:447:m.cs.uiuc.edu:77500064:000:3158
Nf-From: m.cs.uiuc.edu!johnson    Nov 10 19:55:00 1990



craig@Neon.Stanford.EDU (Craig D. Chambers) writes:

> In Self we are rewriting our code to avoid using a
> generic nil object, always initializing variables to "real" objects.
> In some cases we have type-specific null objects that implement all
> the messages that should be understood by objects of the type,
> typically by doing nothing and terminating a recursion.

to which bertrand@eiffel.com (Bertrand Meyer) replies:

>	This is the worst idea I have heard in a
>long time (which means something). When you find that an operation
>is impossible to execute, you just ignore it! What about the
>specification - the contract - that your client expects?

>	In the end, THIS is the real difference. Of course Self,
>like everything else, has void references - they are just called
>null objects.  Where Self, from this description, differs
>from Eiffel, is that an erroneous feature call will simply
>be ignored.

This is not exactly the case.  It is clear that Craig was not
being clear, though that is not exactly his fault.  I first heard
this idea from Allan Wirfs-Broch about two or three years ago,
and it took me awhile to get it.

There are several different ways to use nil in Smalltalk.  One
is as the value of an unassigned variable.  The other is as a generic
"other" or "don't care" value.  A common idiom in Smalltalk is
	x isNil ifFalse: [ x fee. x fi. x foe. x foo ]
nil doesn't understand fee, fi, foe, or foo, but if x is not
nil then x will understand those messages.  Type-checking this
code is funny.   One alternative is to say that nil is a subtype
of every type.  This implies that programs that have been type
checked could still send messages to objects that do not understand
them.  Another is to have the type-checking algorithm use flow
analysis and case analysis (which is the alternative we chose in
Typed Smalltalk).  This makes type-checking expensive and hard
to understand.

The solution is to say that nil is used ONLY for undefined values.
"Don't care" values and "error" values should be user defined objects,
defined specifically for a particular type.  Thus, performing an
operation on an "error" value raises an error, while performing
an operation on a "don't care" object does nothing.  Which one
you use depends on which one you need.

The result is that programs type-check and the type system has the
property that programs that have been type-checked only send
messages that are understood by their receivers.  It might be
that some checking is given up, since the programmer might
mistakenly give a "don't care" object when an "error" object
should have been given.  However, the increase in the quality
of the type-checking might overcome this.

I would be happy to try this technique in Typed Smalltalk,
and indeed we often use something like it in the code that
we write.  However, one of the goals of the Typed Smalltalk
project is to handle typical Smalltalk code the way that it
is written by typical Smalltalk programmers, and this is not
yet the way most Smalltalk programmers program.  Thus, we
cannot depend on it in our type system.

Ralph Johnson -- University of Illinois at Urbana-Champaign