Path: utzoo!attcan!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.object
Subject: Re: testing object oriented programs
Message-ID: <480@tetrauk.UUCP>
Date: 30 May 90 10:38:10 GMT
References: <1990May20.154035.15064@axion.bt.co.uk| <54783@microsoft.UUCP> <5121@stpstn.UUCP> <54917@microsoft.UUCP>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 50

In article <54917@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>In article <5121@stpstn.UUCP| cox@stpstn.UUCP (Brad Cox) writes:
>|The chicken
>|is the object-oriented tools, where by 'object-oriented', I'm referring to
>|open universe languages (Smalltalk, ObjectiveC) that do not insist that the
>|relationship between parts and the whole be known and declared in advance,
>|at compile-time, as the universe is being created by the compiler. In
>|closed-universe languages (Ada, C++, Object-Pascal, etc), i.e. strongly
>|type-checked languages, all such relationships must be known and declared
>|at compile time.
>|
>|- etc -
>
>Well, clearly I disagree with both Brad's notion of "object-oriented" and
>"Open-Closed."
>
>[discussion of open v. closed classes, etc]

I agree with Jim that you cannot limit the world view of object-oriented
programming to untyped languages of the Smalltalk school.  Static typing with
dynamic binding is much more appropriate in many (the majority?) of
applications.

The problem of safe inheritance has been nicely addressed in Eiffel in the form
of assertions, the most important of which is the "class invariant".  For those
who don't know Eiffel, this is a list of boolean expressions in a class whose
truth can be tested at run time every time a routine in the class returns to
the caller.  A failure of course generates a run-time exception.

With inheritance, the invariants of all parent classes are also checked, i.e.
invariants are inherited, and can only be added to, not replaced.  This allows
an inheriting class to overide a routine, but it must still conform to the
invariant.

There is a performance overhead in all this, so invariant checking is a
compile-time option, and can be used to "prove" the software works, then
compiled-out for a production version (assuming you're confident!).

Even if you're not using Eiffel (biased opinion: you should be :-), the idea
can be incorporated in other languages.  Even C has a simple "assert"
mechanism, has anyone tried extending this with C++?

The hardest part is coding discipline, to ensure that you correctly express the
semantics of the class within the assertions, but then coding discipline (or
lack of it) is often the root cause of an awful lot of software errors!

-- 
Rick Jones					You gotta stand for something
Tetra Ltd.  Maidenhead, Berks			Or you'll fall for anything
rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick)	     - John Cougar Mellencamp