From: pf@bilbo.bio.purdue.edu (Paul Furbacher)
Newsgroups: comp.lang.pascal
Subject: Re: Turbo Pascal 7.0
Date: 26 Sep 92 18:47:43 GMT
Distribution: comp.lang.pascal
Organization: Purdue University

In article <1992Sep26.071819.20697@rulway.LeidenUniv.nl>, 
  jeroenp@rulfc1.LeidenUniv.nl (Jeroen W. Pluimers) wrote:

> ... I'd like to have the following construction. 
> 
>    constructor TMYObject.Init;
>    begin
>       INHERITED init;
>       { do own initialisation here }
>    end;
> 
> 
> That way, if you insert an object between some object and their partents,
> you con't have to explicitly change all the ancestor calls.
> 
> This one is suggested by the ANSI group on Object Oriented Pascal and
> I hope it will be implemented by Borland soon.

Perhaps I'm slow to catch-on here but I see all kinds of problems 
and only a narrow solution.  Convince me I'm wrong on the following 
points.  

0.  How often do you do this?  It's not too often that I've done this 
    and it's hard to imagine that the situation arises all that often
    to make it a necessary feature. 

1.  If the intercalated object has a different 
    parameter list, how is that to be handled without digging into the 
    descendents' code? Increasing functionality sometimes requires 
    an increase in the number of parameters.  No savings here as I see 
    it because once again you'll have to dig (usually not too deeply) 
    into the init code of your descendents.

2.  If you obtain a library without source, this doesn't help -- intercalation
    is impossible in the current implementation of OO-TP.  I've often dreamed
    of this kind of retrofit feature.  (You did not specifically mention this 
    as a reason for implementing the above, but I thought you might have it 
    in mind.)

There may be other points I've missed or forgotten already in lining out
those above.  

Again, convince me of how narrow-sighted I am.  Give me the frequency 
with which you redesign your class (oops, object) hierarchy by 
the method of intercalation, thoughts on changing parameter lists, and 
anything else which will win me over.  It may be tough: my vote is "no"
at the moment.

Now, if you proposed a mechanism for correcting the faults or omissions of
a foundation object upon which many others in a library are based (besides
through obtaining the source code, or haranging the authors of the library),
I might vote for that.  Example:

  Let's say you have the following hierarchy with the most "ancient" on the
left (not political, that is):

    TView -> TGroup -> TWindow -> ...
                   |-> TDeskTop 
                   \-> ...

and you realized that there is an indispensible feature which should have
been a part of the functionality of TGroup, and therefore is missing from 
all its descendents.  Without the source code or inside influence with the 
authors of that library, you're stuck with a big problem if you cannot live
without that functionality.  You might have to roll your own beginning with 
TGroup, or start shopping around for a better product, if one exists!

If there were some mechanism to alter TGroup, the problem would be solved.
But this might be a solution for a problem which many others never have. 
I might just be dreaming that this is a problem.

Fortunately, TV was perfectly designed ... well, nearly so.


PF
Newsgroups: comp.lang.pascal