Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!asuvax!mcdphx!dover!digital!norm!shelley
From: shelley@atc.sps.mot.com (Norman K. Shelley)
Newsgroups: comp.lang.eiffel
Subject: Modification of previous enhancement ideas
Message-ID: <48a48a6e.12c9a@digital.sps.mot.com>
Date: 14 Feb 90 18:10:01 GMT
Sender: news@digital.sps.mot.com
Reply-To: shelley@atc.sps.mot.com (Norman K. Shelley)
Lines: 33

New Desired Feature(s) Beyond Eiffel 2.2B (24Jan90) (Modified 14Feb90)
Modifications to a previously posted message.

>3.) When any failure occurs the line number in the source should be printed
>out with the current failure message. 
>    One Supporting Example (many others are possible):
>If more than one inspect statement exists in a routine it becomes a guessing
>game as to which inspect statement really failed.
>
>4.) Assertion labels should be strings so that spaces, uppercase, and
lowercase
>could be supported. This would allow for more readable failure messages.

A modification of numbers three and four would be:
3.) When compiling a system in "make source code available" mode a
failure ought
to cause a viewer to appear with the appropriate source code in the viewer and
an arrow pointing to the line which failed.

4.) Assertion labels can be misleading and if an assertion is modified
the label
should be probably be modified also. The label is redundant in many cases and
the assertion is all one might need to see, so in addition to possible string
assertion labels a system like that suggested in feature  number three
(modified) would be VERY adequate on assertion failures

Norman Shelley
Motorola - ATC
2200 W. Broadway AZ09/M350
Mesa, AZ 85202
...!uunet!dover!atc!shelley
shelley@atc.sps.mot.com
(602) 962-2473