weiner@novavax.UUCP (Bob Weiner) (04/07/90)
In article <2047@clyde.concordia.ca> marcap@doyle.cs.concordia.ca (PAWLOWSKY marc) writes: >In article <276@eiffel.UUCP> nosmo@eiffel.UUCP (Vince Kraemer) writes: > >< Also worth noting, we see assertions as a development tool. >< They are to be stripped out (via recompilation) at delivery >< time. ... >Loop invariants (certainly) and postconditions (possibly) may be too >expensive to keep, but active preconditions are an invaluable aid in >maintaining professional software systems. I disagree that preconditions should be necessarily checked since routines that are called from the same class have very little excuse not to pass the preconditions. Most times when I call a routine within a class it is to save code length, otherwise it could just be typed in full in the calling routine. What this thread seems to be skirting around is the idea that most programs have a need for both run-time-enabled and compile-time-enabled assertion checks, not simply one or the other. A run-time-enabled assertion is always checked whenever the program is run or when some particular flag is set in the program. A compile-time-enabled assertion check is turned on or off at compile-time, as are the 'require', 'ensure', 'check', and 'invariant' clauses in Eiffel. A language interested in supporting assertions should probably provide distinct mechanisms for each type. (In Eiffel today, one generates run-time assertions by simply including specific checks in the code and then raising an exception if any one fails.) This seems adequate to me, but such a technique is not emphasized as it should be in Eiffel: The Language or Object-oriented Software Construction. The tough issue this raises is which assertions should be permanent (run-time) and which should be enabled/disabled at compile time? I still don't have a good answer for this though it has been bothering me for some time. In a language such as C where any trace of an assertion facility is but an optionally included header file, programmers are much more likely to code all of their significant run-time checks as part of the normal code. In Eiffel, people become dependent on assertions which they no doubt turn off the instant performance becomes an issue. As pointed out in earlier messages, this is equivalent to tossing your life vest away just when you need it. My solution is simply to educate people as part of their OO training in how to distinguish between compile time and run-time assertions. Then let them go out and make this decision on a case by case basis. I see no need for anyone to generate a design technique that attempts to decide such things for the programmer, even if said programmer is a machine. -- Bob Weiner, Motorola, Inc., Usenet: ...!gatech!uflorida!novavax!weiner Internet: novavax!weiner@uunet.uu.net (407) 364-2087