Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!alonzo From: alonzo@microsoft.UUCP (Alonzo GARIEPY) Newsgroups: comp.lang.eiffel Subject: Re: Assertion tags Message-ID: <10509@microsoft.UUCP> Date: 8 Feb 90 17:48:09 GMT References: <120005@gore.com> <1758@esquire.UUCP> Reply-To: alonzo@microsoft.UUCP (Alonzo GARIEPY) Organization: Microsoft Corp., Redmond WA Lines: 32 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.