Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!m.cs.uiuc.edu!render
From: render@m.cs.uiuc.edu (Hal Render)
Newsgroups: comp.object
Subject: Re: testing object oriented programs
Message-ID: <1990May31.224646.15066@ux1.cso.uiuc.edu>
Date: 31 May 90 22:46:46 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> <3754@trantor.harris-atd.com>
Sender: usenet@ux1.cso.uiuc.edu (News)
Reply-To: render@m.cs.uiuc.edu.UUCP (Hal Render)
Organization: University of Illinois, Dept. of Comp. Science, Urbana
Lines: 68

In article <3754@trantor.harris-atd.com> wdavis@x102c.ess.harris.com writes:
>In article <1990May30.204110.22011@ux1.cso.uiuc.edu> render@m.cs.uiuc.edu writes:
>>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?

I think it is generally better to provide a direct solution to a problem
rather than a round-about one.  I have frequently had to rely on "coding
discipline" to do something that I felt a language should offer me as
a feature.  In this case, the problem is someone redefining a method so
that it no longer meets the original intent.  My principal problem with
relying on class invariants to prevent such redefinition is the difficulty
one often has in formulating a useful invariant for a particular piece of
code.  I admit that part of my lack of confidence in this may be due to 
the lack of practice I have had in formulating invariants.

>[Description of the value of redefinition ommitted.]
>Do you have some equally compelling reasons why the prevention
>should be considered better?

Preventing errors is always a tricky thing.  Upon reflection I do concede 
that it could cause just as many problems for the users to forbid them 
to redefine certain methods as it would be for the designer to formulate
invariants that are strong enough to prevent undesirable redefinitions
yet weak enough to allow desirable ones.  The problems are subtle, and
I will need to examine them more before I can say anything useful about 
the good/bad points of class invariants.

>>this [feature] sounds neither far-fetched nor difficult to implement. 
>
>Just because it is easy to implement does not mean it is a good idea.

True, but my point was that difficulty of implementation would not be a 
point against it.

>>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").

I think you're reaching on this one.  I did not propose outlawing
redefinition, only the ability to prevent it for specific methods.  
I see the value in such language-supported constraints because I am 
now in the process of writing a fairly complex Smalltalk application.
Frequently I find that I would like to be able to constrain the visibility
of methods to both subclasses and container classes to prevent unintended
violations of the semantics of the class.  Unfortunately, Smalltalk does not 
support such constraints, so consequently I must rely on "coding discipline" 
to safeguard myself against errors.  Since I am a fallible human, coding 
discipline has occasionally failed me, so I am leery of people who suggest
it as an alternative for more direct language support.   As I said, I do 
see the potential problems with being able to blindly restrict redefinition,
but I have also faced the problems that such redefinition can cause in 
the conceptual integrity of a class hierarchy.

Constraints, by their definition, are intended to prevent some sort of
activity.  We include them in a language to prevent "undesirable"
activities.  Of course, what seems undesirable for one person may seem 
highly desirable to another, so we have disputes such as this.  

hal.