[Mono-list] Design by Contract

[Stephen Touset]

--=-l3mTVUM3fjYCfmUczvzG
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2004-12-31 at 18:17 -0500, Robert Shade wrote:
> Just to add my two cents, I think I would discourage the attribute idea.
>=20
> For one, it would mean that your compiled application would have to link=20
> with your DBC library.  This would mean that the user would have to deal=20
> with a bunch of #if's so that those attributes would not be compiled in=20
> production code. Otherwise, the user would be forced to distribute your=20
> library with their product.

Well, there wouldn't be a lot of #if statements, as far as I know. A
failure of the preconditions indicates that there's a bug in your user's
code. A failure of the postconditions or invariants indicates that a bug
exists in your code. Because of this, there are really two use cases
(although a bit more fine-grained tuning could be used without requiring
you to be overly verbose).

Firstly, debugging. You want everything on. That way, you can ensure
that your code is working as expected. If any postconditions or
invariants fail, you know that your code is not holding up its end of
the bargain..

The second case is in release code. You want only preconditions on. The
postcondition and invariant checks will probably be too slow to use in
release code, and by that time you've already (theoretically) debugged
your application. Unit testing combined with postconditions/invariants
should discover a significant number of those bugs, and give you the
confidence to disable them. Preconditions, however, would still be
enabled. Since most functions already put lines in the beginning of
functions anyways to test variable constraints, this would simply shift
the placement of these tests from code to metadata.

> Secondly, attributes would force the checking to be done by a modified=20
> compiler.  This would seriously limit your target audience to mono=20
> folks.  Love mono, but the masses are using Microsoft's compiler.

Yeah =3D\

> An external tool would also allow you to investigate the code flow in=20
> ways that the compiler may not.  For example, you could do "process"=20
> time checking of the code to see if your "contracts" are always=20
> true/false.  (I belive the MS compiler does this for conditionals)  For=20
> things that were marked "invariant", you could follow the code flow to=20
> see if these are modified at any point.  You'd perhaps even be able to=20
> warn the user under exactly what conditions the contracts would fail.=20
> If you had that functionality, you would completely eliminate the need=20
> for the user to have the (runtime) contract checking code present.  The=20
> user would already know precisely under what conditions errors would=20
> occur and could add exception handling to take care of it.

I'm not quite sure if this kind of approach would work. Design By
Contract explicitly states when contracts need to be checked, so having
an external application that does process-time checking would be
difficult to implement in this way.

Also, preconditions are something you (almost) always want checked, so
requiring a third-party application in this case seems even worse than a
third-party library. Especially so, because any libraries which
implement Design By Contract would then be forced to redistribute the
application, and their clients would be forced to run it.

In all, I want to avoid having to write a bottom-up parser for C#, or
even rip out mcs' C# parser, and use it for my own needs. Is there some
method of putting hooks into mcs, so that I don't have to modify the mcs
code itself?

--=20
Stephen Touset <stephen@touset.org>

--=-l3mTVUM3fjYCfmUczvzG
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBB1tfe+fMdKwQeHvYRAijIAJ9QZqVgMA5RTHIFW4IvChJrAHd3ZQCfWqRD
pUyTlWBZe7N7vcrwVXke3uk=
=A8w8
-----END PGP SIGNATURE-----

--=-l3mTVUM3fjYCfmUczvzG--