Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!ucsd!hub.ucsb.edu!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.object
Subject: Void references
Summary: Doing nothing is not the proper way to get out of error situations
Message-ID: <447@eiffel.UUCP>
Date: 9 Nov 90 21:01:45 GMT
References: <443@eiffel.UUCP> <1990Nov7.220902.13393@Neon.Stanford.EDU> <1990Nov9.010930.26493@Neon.Stanford.EDU>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 80

From <1990Nov9.010930.26493@Neon.Stanford.EDU>,
craig@Neon.Stanford.EDU (Craig D. Chambers) writes:

> [...] 
> What are you saying?  That you didn't make the comments that I
> attributed to you?

In mail to Mr. Chambers I listed the points on which I believe he
attributed to me ideas which are the contrary of what I wrote, which
is why I just cannot participate in that part of the debate (static
typing). I'd like to confine any controversy to technical issues,
rather than each person's (recursive) understanding of another's
comments, so I'll stop here. By the way, it is quite clear that
if Mr. Chambers did misunderstand my points that may be partially
or even totally my fault - for not being clear enough. 

On void references:

1. A void reference by any other name (nil, NONE, null object etc.)
is still a void reference.

2. 

> 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.

	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 policy, of course, could have been implemented in Eiffel
(as it could be in Simula or anything else) by accepting that x.f
does nothing if x is void. But this is not acceptable!
If there is an illegal call, we want it to signal failure by raising
an exception - NOT to fake success!

	Just to drive the point closer: if I have the call

	landing_gear.raise

in a flight control software system, then I certainly would check
very carefully, by static means, that landing_gear will never be
void (null, nil ...) when this is executed. Once I have indeed
checked, if, for some reason (which can only be a bug,
although if there is some fault-tolerance in the software a
rescue mechanism may be available), landing_gear does happen to be
void at run-time, is the proper reaction to do nothing and
wait quietly?

	``Ladies and Gentlemen, we are starting our final
	approach towards Stanford. For reasons too complicated
	to explain in detail, you may wish to fasten your seat belts.
	We hope that if you future plans call for air travel ...''

	I believe that this is not proper. The proper
reaction is to trigger an exception, with the hope, of course,
that there is some exception handling code - even if all that code
does is to flash a light on the pilot's control board.

-- Bertrand Meyer
bertrand@eiffel.com