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
---------------------------------------------------------------------------