Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.object
Subject: Re: testing object oriented programs
Message-ID: <483@tetrauk.UUCP>
Date: 4 Jun 90 09:53:21 GMT
References: <1990May31.224646.15066@ux1.cso.uiuc.edu> <9189@bunny.GTE.COM>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 57

In article <9189@bunny.GTE.COM> dcr0@GTE.COM (David Robbins) writes:
>From article <1990May31.224646.15066@ux1.cso.uiuc.edu>, by render@m.cs.uiuc.edu (Hal Render):
>> 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.
>
>This last statement is really a *key* point.  At least part of the problem
>under discussion here is that a subclass may redefine methods in a way that
>breaks non-redefined methods.  In other words, the redefined method violates
>some assumption the broken method makes.
>
> -- etc

I think David has put his finger on the nerve of this thread.  While most of
the work in the field of OOPL's seems to be focussing on the mechanics of the
languages, the wider issue of how they can support a reliable software design
and engineering method is not really being addressed.  As he says, Eiffel has
made a significant step in the right direction with assertions, which while
being far from perfect are a lot better than nothing.  They are in fact one
of the major reasons why I'm using the language.

Eiffel's assertions support a semi-formal definition of the class interface
in relation to clients.  This discussion has been about the definition of the
interface in relation to descendants, for which it (let alone any other
language) does not provide any mechanism.  I would very much like to see
Eiffel take a new lead in addressing this problem.

I believe that for software to be flexible and reliable, and for the great
Nirvana of "bags of reusable software components" to become a serious reality,
classes must *always* be extensible and adaptable by inheritance provided
that they conform to whatever interface constraints are specified for the
parent.  Ducking the problem by saying "non-redefinable" is not the real
answer;  the constraints must be good enough to say what you mean.

Traditionally issues like this have been regarded as part of the "development
environment", rather than the province of the language itself, but one of the
benefits of a good OO development strategy is that it can (and must)
integrate everything.  This ultimately means that OOPL designers have got to
start incorporating serious constraint definition into the languages as well
as all the standard stuff for expressing executable routines.

IMO the supposed quantum leap in software productivity and reliability will
not materialise and OO will all look like a lot of hype in a few years time
unless the languages take on a wider view of what "programming" is, and
embody capabilites which more represent "design & build".

-- 
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