Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!ncrlnk!ncrcae!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: <5769@hubcap.clemson.edu>
Date: 14 Jun 89 21:37:04 GMT
References: <130200003@p.cs.uiuc.edu>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 48

From article <130200003@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu:
> I'm not concerned about the component builders as much as the component
> users.  Building an application is often similar to rapid-prototyping,[...]
> Inheritance lets you modify components that are not quite right.  
> [...] extension essentially adds dynamically bound procedure calls to Ada.

From adamsf@cs.rpi.edu (Frank Adams):
> I suspect that software components in object form will never be successful.
> There is too much need to diddle with things, too little which can be used
> as is.  And inheritance with run-time binding is too often an inadequate
> method of diddling.

   OK, it is becoming clear that there are some different sets of
   underlying assumptions here, so let's identify them for discussion:

      1) It is fairly unlikely that any particular component will
           fit the application developer's requirements, hence they
           must be rapidly modifiable as with inheritance.  For some
           reason, using a tool which automatically constructs a
           higher level of abstraction (for appropriate modification)
           isn't appropriate, even though this also isolates the 
           specification from the implementation.

      2) For some reason, run-time binding is necessary.

      3) Even run-time binding may not be enough.

   Regarding 1), I have exactly the opposite perspective; in general,
   either a component is readily available (mostly the case), or it
   gets invented on the spot.  Furthermore, in the very unlikely event 
   that I need to slightly modify an existing ADT, a tool can be used to
   generate another level of abstraction and proceed from there. 
  
   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".

   So perhaps Ralph and Frank could provide some insight as to why
   they (apparently) hold the above assumptions, editing the above
   listed assumptions as necessary to reflect their actual positions...


   Bill Wolfe, wtwolfe@hubcap.clemson.edu