[E-Lang] Syntax change: reducing side-effects

Monty Zukowski mzukowski@bco.com
Mon, 12 Feb 2001 07:50:20 -0800


> Ignoring the thunking of the second argument, this seems an
> awful lot like
> an assert.  However, it has one crucial difference which
> takes E farther
> from Eiffel.  An assert is an optional check.  A require is a
> mandatory one.
> Our guards also differ from Eiffel's checks in this way -- they also
> express mandatory check.  These checks are part of the
> semantics of the E
> program.  If you removed them from a correct E program, or
> somehow silently
> turned them off, you would have a broken program.  The removal is not
> correctness preserving.
>
> For invariants and post-conditions, this is probably a weakness of E
> compared to Eiffel.  For Eiffel's design goals, this
> inability to turn off
> E's pre-condition checking would also be seen as a weakness.
> However, for
> E's design goals, an object with *optional* preconditions checking is
> probably a security hole.  With such checking off, it "relies" on its
> clients, and so is "delicate".  While on rare occasions it is
> appropriate to
> code a delicate object, capability style is to avoid these
> like the plague.
> An object's correctness should almost never be at the mercy
> of the behavior
> of its clients.  The occasional delicate object should be painted in
> blinking red neon polka dots, so no one forgets to handle it
> with care.

Eiffel's invariants and post-conditions are used mainly for debugging objects.
Normally they are turned off when a system goes to production, for performance
reasons.  Pre-conditions are normally left on to protect yourself from malformed
calls.  Another really nice thing about the DBC notations are that they are
automatically extracted into documentation.

Does E have any support for "#ifdef DEBUG" kinda stuff?

Monty

Monty