Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.sw.components
Subject: Re: Inheritance vs. component efficienc
Message-ID: <5791@hubcap.clemson.edu>
Date: 16 Jun 89 19:10:38 GMT
References: <TED.89Jun15113933@kythera.nmsu.edu>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 93

From ted@nmsu.edu (Ted Dunning):
> there seems to be a collision of programming styles going on in this
> group.  in particular, the edit/compile camp insists that run-time
> flexibility is not really needed since most of the work of
> instantiation and inheritance can be done at compile or edit time,
> while the interactive/run-time binding camp insists that this is not
> sufficient.

    Strongly agree with this.
  
> while it is true that having an editor write interface and
> implementation code effectively provides the necessary mechanisms of
> inheritance, this ignores the fact that the programmer is left with a
> LARGE mass of code to work with.  anyone who has tried to write a new
> x-window widget that is only a trivial specialization of an old one
> can tell you that there is a HUGE amount of code that you have to
> learn to ignore.  this overhead should be hidden from the programmer
> to simplify the reading of the code (even after you have learned to
> ignore huge chunks of stuff), and also to prevent inadvertent
> modification.

    Counterpoints would be:

       - If an object has vast numbers of operations available 
           upon it, then either this correctly represents the
           actual complexity of the object's definition (in which
           case they should all be directly visible), or the object
           is defined in an overly complex manner and should be simplified.

       - Why would there be a problem with accidental modification?
           If you modify something, you must as a matter of course
           know precisely what you are doing and why.  (No?)
  
> secondly, having an inheritance mechanism built into the language will
> likely have the secondary consequence that the mechanism will be built
> into the debugges for the language.  trying to debug an object
> oriented program without support from the debugger is similar to
> trying to use a debugger which does not support structure display.  a
> debugger must avoid presenting the programmer with excessive detail as
> a default.

    Where would the excessive detail arise?  Generally, you suspect a
    particular procedure, and use the debugger to "step into" it directly.

%       Regarding 2) and 3), I don't perceive any need for run-time binding.
%       Even if we were to define classes of types (characterized by the
%       operations which it has available) and allow procedure parameters
%       to be described in terms of such classes, this still would simply 
%       amount to a more readable version of "this procedure is generic in 
%       the type of this parameter; auto-instantiate as necessary after 
%       determining at compile time the type of the actual parameter".
% 
% you can't be seriously saying the the equivalent of c++ virtual
% functions is not needed.  it is crucial that you be able to pass
% around an object which is declared to be a relatively general object
% but which is in fact some unknown (to the code at run-time)
% specialization.  
% 
% if you aren't saying this, then you must be saying that the extent of
% genericity of a class can be determined at compile time.
% 
% if so, consider a program that reads a textual description of objects
% to be instantiated.  this is a simplification of what an interpreter
% for an object oriented language must do.
% 
% how in a completely compile oriented environment can you provide
% consistent instantiation mechanism in this case?  must you resort to
% the fabrication of an entire run-time class inheritance scheme from
% whole cloth?

   Well, technically it is possible to do instantiation at run time
   if necessary, although we compile-oriented types vastly prefer to
   pay the price only once at compile time if at all possible.  Briefly,
   you set up a local block, and instantiate inside it:

      declare
         package Whatever is new Something (A, B, C...);
      begin   
         -- make use of your newly instantiated package...
      end;

   The generic parameters A, B, C... are determined at run time;
   for example, they could be parameters to a surrounding procedure.
   Clearly this can lead to bug situations which will be extremely 
   difficult to track down (since they only arise in some particular, 
   possibly complex, run-time situation) if we are not very, very careful.

   It's considered a risky situation, to be avoided like the plague unless 
   absolutely necessary; when it is absolutely necessary, one must proceed 
   with extreme caution. 
 

   Bill Wolfe, wtwolfe@hubcap.clemson.edu