Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!hub.ucsb.edu!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.object
Subject: Re: Void references
Summary: What run-time errors will remain?
Message-ID: <454@eiffel.UUCP>
Date: 14 Nov 90 18:17:19 GMT
References: <1990Nov7.220902.13393@Neon.Stanford.EDU> <MOSS.90Nov14094958@ibis.cs.umass.edu>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 86


Two more comments after Craig Chambers's and Eliot Moss's
last postings.

1. The technique using two variants of list cell descriptions
(two heirs to a class CELL or LINKABLE), one to represent
internal cells and another to represent terminal cells,
can be implemented in any object-oriented language.
I do not find it particularly attractive:

	A. It seems to require at least as much code as
	using a vacuity test.

	B. One may also question the claim that it is
	``more object-oriented''. Are we to understand that
	the conditional instruction
	is not object-oriented? This is going too far.
	Good object-oriented style implies getting rid
	of certain conditional instructions (those which
	discriminate among a number, often large, of
	data types, especially if the list of choices
	is bound to change). The philosophy that I see behind
	Mr. Chambers's method (although he did not express it
	in that way) is that whenever technically feasible
	an explicit test should be replaced by dynamic binding.
	I may be misrepresenting his position, in which case
	he'll correct me; if so, however, this means there is
	room for conditional instructions, and the discrimination
	between void and non-void references (or terminal and
	non-terminal cells) seems to be a legitimate case for
	such instructions.

	C. The prospect of having to write TWO classes for
	every kind of cell (list element, tree node, ...),
	is rather unpleasant.

	Apparently this is easier in Self because it's
	not really classes but objects.
	But here I quit. Object-oriented programming
	as I understand it has little to do with objects;
	it is really about classes. Why one should try to have
	O-O Programming without classes, the major facility of
	the method, is beyond my understanding.  I should probably
	have kept my mouth shut, but it's too late.
	(The term ``Class-based analysis, design and programming''
	is what I personally would use to characterize the field.
	By the way, I have never understood the rationale behind
	distinctions such as ``object-based'' vs. ``object-oriented''.
	If we are using English, it would seem that terms such as
	``based'', ``oriented'' and the like should retain a meaning
	which is reasonably close to their usual sense, and technical
	terms such as ``object'' should be used in their accepted technical
	sense. What does the distinction between ``based''
	and ``oriented'', if any, have in common with the distinction
	between encapsulation languages such as Ada, supporting a certain
	module structure, and approaches such as Smalltalk's or Eiffel's
	supporting a module and typing structure based on classes?
	How do Ada ``objects'' differ from those of Pascal?
	In what way does the use of such terminology improve our
	understanding of the issues? But by now I have probably opened
	too many cans of worms anyway.)

2. On the topic of errors: It is nice to see that apparently
everyone agrees that there may remain errors at execution-time.
The next question is: which ones? I have described a framework
(Eiffel's) in which, assuming a perfect compiler, only three kinds
of errors may remain:

	A. Attempt to call a feature on a void reference.

	B. Assertion violation.

	C. Hardware or operating system fault (e.g. arithmetic overflow).

In a theoretical study, case C would disappear, being covered by
A and B.

I believe this is clean, intellectually satisfying, practically
convenient, and easy to explain. It is certainly not in the only
possible solution.  But it is essential that anyone claiming that
language or environment X ``solves the problems'' of errors of
a certain type (e.g. vacuity of references) should also state what
are the categories of possible run-time errors that DO remain. 
 
-- 
-- Bertrand Meyer
bertrand@eiffel.com