Path: utzoo!attcan!uunet!cs.utexas.edu!usc!ucsd!nosc!logicon.com!trantor.harris-atd.com!x102c!wdavis
From: wdavis@x102c.harris-atd.com (davis william 26373)
Newsgroups: comp.object
Subject: Re: testing object oriented programs
Message-ID: <3754@trantor.harris-atd.com>
Date: 31 May 90 19:40:38 GMT
References: <1990May20.154035.15064@axion.bt.co.uk| <54783@microsoft.UUCP> <5121@stpstn.UUCP> <54917@microsoft.UUCP> <480@tetrauk.UUCP> <1990May30.204110.22011@ux1.cso.uiuc.edu>
Sender: news@trantor.harris-atd.com
Reply-To: wdavis@x102c.ess.harris.com (davis william 26373)
Organization: Harris Corporation GSS, Melbourne, Florida
Lines: 54

In article <1990May30.204110.22011@ux1.cso.uiuc.edu> render@m.cs.uiuc.edu.UUCP (Hal Render) writes:
>In article <480@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes:
>>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".

(rest of the Eiffel discussion deleted)

>Although class invariants are A Good Thing, I think that a more direct 
>mechanism that prevents a method from being redefined in a subclass
>would be better in this case.

Why do you think it is better?

To have a class be able to specify that a method cannot be redefined
assumes that there is not a good reason for the redefinition.  Even if
there is no good reason at the time the class is written, there may
be a good reason in the future.  Just trying to determine if there
could be a good reason at the time a class is designed can become an
unbounded "what-if" game.

The benefit of being able to extend a class via inheritance in a way
that the original class implementor did not consider is a powerful
method of software development.  The "safe" aspect is the question of:
"What did the original implementor intend as the constraints?"
I think this is very well addressed in the notion of "Programming
by contract" that is described by Dr. Meyer as the basis for
the invariants used in Eiffel.

Do you have some equally compelling reasons why the prevention
should be considered better?

> There are already with different kinds
>of inheritance/visibility constraints for methods in some OOPLs, and 

Each constraint in a language comes because it has benefits that,
in the opinion of the language designer(s), outweigh the cost
that comes from not having the feature.  Just because other languages
have have certain restrictions, this does not mean those restrictions
would be a good idea in a new language or even a new version of the
same language.

>this one sounds neither far-fetched nor difficult to implement. 

Just because it is easy to implement does not mean it is a good idea.

>Further, it avoids the need for "coding discipline" that is the cause
>of many program errors.

Taking away valuable functionality because some people are going to
have problems using it is not always the best way to design a language.
Should we remove all loop constructs because it is possible to make
a mistake and have the loop not terminate?  We cannot have the language
ensure that all loops terminate (unless someone has solved the general
case of the "halting problem").