jwg1@gte.com (James W. Gish) (02/01/90)
In article <1758@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: > I think assertion tags should be strings, not > identifiers, like this: > "non-void widget": not w.Void Why ? I don't see the advantage. -- Jim Gish GTE Laboratories, Inc., Waltham, MA CSNET: jgish@gte.com UUCP: ..!harvard!bunny!jwg1
shelley@atc.sps.mot.com (Norman K. Shelley) (02/03/90)
In article <JWG1.90Jan31164048@bunny.gte.com>, jwg1@gte.com (James W. Gish) writes: > In article <1758@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: > > I think assertion tags should be strings, not > > identifiers, like this: > > "non-void widget": not w.Void > Why ? I don't see the advantage. > -- Advantages: 1.) When an assertion fails the tag is printed out ALL in lower case because Eiffel is case insensitive. A string would allow upper and lowercase characters which allows for more readable assertion failure messages. 2.) A string also would allow the use of whitespace to delineate words which would dramatically improve readability of the assertion failure message. Norman Shelley Motorola - ATC 2200 W. Broadway M350 Mesa, AZ 85202 ...!uunet!dover!atc!shelley shelley@atc.sps.mot.com (602) 962-2473
alonzo@microsoft.UUCP (Alonzo GARIEPY) (02/09/90)
In article <1758@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: > I think assertion tags should be strings, not identifiers, like this: > > foo( w: WIDGET ) is > require > "non-void widget": not w.Void > Is there anyone who disagrees with this? You haven't given any reasons, so it's hard to agree. I happen to be working on assertions just now and find that the identifier approach gives better performance (admittedly, that isn't much of an issue in Eiffel). The reason is that assertions can be resolved at run time by referring to the link map without having to compile strings into the code. The per assertion overhead is then only a few bytes in addition to the compiled test expression. Without question, the most useful piece of information, besides file and line number, for a programmer to have when an assertion fails is the code of the test itself. Assertion strings are typicallly a restatement of the test and somewhat redundant. The source code itself (along with any comments) is more useful than any identifier or string. An identifier is a convenient handle for remembering and manipulating (e.g., logging) assertions. For that use it is best kept as a single concise token. (On a side note: I would be interested in hearing more feedback about the problem of conformance of parameters in function redefinition. I haven't gotten any response from Meyer on this, but if I am not mistaken, it breaks the idea of programming as contracting, and makes for simple construction of "type safe" programs that crash. ) Alonzo Gariepy // These opinions are not necessarily alonzo@microsoft // those of Microsoft Corporation.