Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!ucsbcsl!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: Multi-branch instructions and unique values (Version 2.2 preview)
Keywords: Case, Enumeration
Message-ID: <131@eiffel.UUCP>
Date: 26 Mar 89 00:23:27 GMT
References: <122@eiffel.UUCP> <1638@etive.ed.ac.uk>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 55

From <1638@etive.ed.ac.uk>, db@lfcs.ed.ac.uk (Dave Berry):

> Would it not be possible to extend the notational facility
> [for intervals, e.g. 3..5]
> to constants declared in the same declaration? [If]
> 
>   blue, white, red: INTEGER is unique;
> 
> were taken to mean that the unique values given to
> blue, white and red must be consecutive, tests could be made against
> the ranges  blue..white,  white..red  and  blue..red.

	The above is defined formally as a syntactical abbreviation for

   blue: INTEGER is unique;
   white: INTEGER is unique;
   red: INTEGER is unique

	In Eiffel, the order of declarations of features within a
class is immaterial. I would hesitate to make an exception to this rule.

	I have always been uneasy with the ordering that exists between
the values of an enumeration type in Pascal, and in particular with
the predefined ``ord'' function. I believe it is preferable to think
of enumerated values in Pascal, or ``unique'' values in Eiffel, as
elements of a set rather than of a sequence.

	This is largely a matter of taste. I am not claiming that there
is just one correct answer.

> The references I have on Eiffel are strongly against exceptions,
> so I presume they're out of date!

	They must be quite old indeed. I was so shocked by the Ada
exception mechanism that for a while I was dead set against exceptions.
After looking more carefully at assertions, however, I realized
that there is a need for a disciplined exception mechanism, based
on program correctness techniques and on an analysis of what
``abnormal case'' means from a theoretical viewpoint. This mechanism
was incorporated into Eiffel. In my biased view it is one of Eiffel's
main contributions to software engineering.

	The methodological rationale and the mechanism itself are described
in detail in an article entitled ``Programming as Contracting'',
which has been sitting for about two centuries in the refereeing
process of a journal. Various bits of the article found their way
into section 7.10 of ``Object-Oriented Software Construction'',
into a recent paper in Springer-Verlag's ``Structured Programming''
journal (Vol. 10, no. 1, pp. 19-39), and into the next installment of
the Eiffel column in the Journal of Object-Oriented Programming,
due to appear (I think) in May.
-- 

-- Bertrand Meyer
bertrand@eiffel.com