On 09 Jul 2000 16:17:44 -0500,
Dave Thomas <Dave / thomases.com> wrote:

>Using these combinations, I _think_ there's enough power to be able to 
>wrap existing methods in pre- and -post condition handlers (where the
>post-condition handler also checks the class invariant), and to be
>able to perform the wrapping on subclasses when needed. That was the
>approach I was considering.

In Eiffel, invariants are checked before *and* after the execution of an
*exported* routine (no invariant checking for private routines!). I do
not have the rationale available in my mind right now ;-), but it is
clearly discussed in OOSC2.

>I couldn't see a way to determine that 'n' was a parameter. Apart from 
>this problem, I agree with Andy that DbC could be added with no
>interpreter mods.

In general, I agree, too. But I see many obstactes to this:

	- Inheriting assertions.

	- Enforcing that pre-/postconditions are weakened/strengthened in a
	  subclass by enforcing the use of another keyword.

	- Convenient implementation of "old" expressions.

	- Recursive assertions. If "pre" or "post" calls a feature that
	  returns a boolean and that itself has a "pre" and/or "post", these
	  contracts are *NOT* checked.

-- 
Best regards,
Patrick 

-- 
---------------------------------------------------------------------------
            	  e-mail: pschoenb / solidsoft.iksys.de
                  URL: http://www.geocities.com/Vienna/5357/
 PGP Public Key: Mail to pgp / solidsoft.iksys.de with 'pschoenb' as subject
     Fingerprint: 3C FB B0 A7 E2 C2 3B 2D  68 6C 66 7E B7 D5 C2 70
---------------------------------------------------------------------------