From: nobody@REPLAY.COM (Anonymous)
Subject: Re: maintenance of overriding subprograms
Date: 1997/09/10
Date: 1997-09-10T00:00:00+00:00 [thread overview]
Message-ID: <199709101328.PAA21175@basement.replay.com> (raw)
In-Reply-To: 340C2EA5.B9F@gsfc.nasa.gov
<341065D7.4D41@gsfc.nasa.gov> <EG54sG.D2F@world.std.com>
<34145A2F.3659@pseserv3.fw.hac.com>
On Tue, 9 Sep 1997 13:25:22 GMT, bobduff@world.std.com (Robert A Duff)
wrote:
> In article <34145A2F.3659@pseserv3.fw.hac.com>,
> W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
> >If your names are well-chosen, and your hierarchy well-designed,
> >wouldn't it be unnecessary (except for the occasional extreme case)
> >to hunt down a lot of other stuff to understand the item at hand?
>
> I don't think so. If I see:
>
> package P is
> type T is new Some_Parent with ...;
> procedure Foo(X: T);
> private
> ...
> end P;
>
> How on Earth am I supposed to know about the 17 primitive operations of
> type T? If Some_Parent is heavily used, then maybe I've memorized them,
> but otherwise, I can either go look them up, or use a tool that collects
> them for me. I prefer to have the latter, at least as an option.
How are you supposed to know about all the inherited operations of type
T? You aren't, and the tool you prefer will not be available when you
need it (I know this from experience). Note that this is true even if
Some_Parent is not tagged. Anyone who creates such code is not a
software engineer, since the result violates the principle of locality
and consists of highly coupled modules.
>
> >Conversely, if one has to study all the ancestors in great detail
> >to do anything with a particular descendant, haven't we lost much of
> >the reduced work alleged to be acheived by inheritance?
>
> Well, not really. For example, think of all those clients of the
> *parent* type that happily use the derived type without even *knowing*
> about it.
>
> It depends who's doing the "alleging", I guess. It ranges from "OOP is
> a useful tool" to "OOP will cure all the world's ills". ;-)
We've known for 30 years that high coupling among modules is bad. We've
also known for long enough that inheritance creates highly coupled
modules. Therefore, [conclusion left to the reader as an exercise].
Jeff Carter PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Go and boil your bottom."
Monty Python & the Holy Grail
Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/
next prev parent reply other threads:[~1997-09-10 0:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-09-02 0:00 maintenance of overriding subprograms Stephen Leake
[not found] ` <340DCE1D.6C5F@bix.com>
1997-09-04 0:00 ` John G. Volan
1997-09-07 0:00 ` Robert Dewar
1997-09-08 0:00 ` Robert A Duff
1997-09-09 0:00 ` Dan Johnston D.B.
1997-09-09 0:00 ` Tom Moran
1997-09-09 0:00 ` W. Wesley Groleau x4923
1997-09-10 0:00 ` Robert Dewar
1997-09-11 0:00 ` Dan Johnston D.B.
1997-09-12 0:00 ` Richard A. O'Keefe
1997-09-12 0:00 ` Samuel Mize
1997-09-18 0:00 ` Shmuel (Seymour J.) Metz
1997-09-24 0:00 ` John G. Volan
1997-09-25 0:00 ` Shmuel (Seymour J.) Metz
1997-09-26 0:00 ` Richard A. O'Keefe
1997-09-12 0:00 ` Robert Dewar
1997-09-05 0:00 ` Robert Dewar
1997-09-05 0:00 ` Stephen Leake
1997-09-05 0:00 ` Matthew Heaney
1997-09-07 0:00 ` Robert A Duff
1997-09-08 0:00 ` W. Wesley Groleau x4923
1997-09-09 0:00 ` Robert A Duff
1997-09-09 0:00 ` Jon S Anthony
1997-09-08 0:00 ` Tom Moran
1997-09-08 0:00 ` Stephen Leake
1997-09-10 0:00 ` Anonymous [this message]
-- strict thread matches above, loose matches on Subject: below --
1997-09-10 0:00 Marc Wachowitz
1997-09-29 0:00 Marin David Condic, 561.796.8997, M/S 731-96
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox