🚀 go-pugleaf

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.