🚀 go-pugleaf

From johnson@p.cs.uiuc.edu:
> > [re: automatic generation of a higher level of abstraction]
> 
> This is called delegation, which is a common way of implementing
> inheritance in object-oriented languages.  One problem is that
> if you inherit procedure X, which calls procedure Y, but redefine
> Y then the inherited version of X will call the wrong version of Y.

  If Y is redefined, then the implementation of X will become obsolete,
  and one can then take whatever steps are deemed necessary.  One could
  have the tool copy code as an option, of course, which in all probability
  would prove quite useful when it came time to reimplement more efficiently.

  One of the reasons I'm not terribly fond of inheritance is that it doesn't
  correspond to the "natural" way in which reasoning about objects typically
  proceeds.  We did not first conceive of the general concept of fruit; 
  rather, we discovered one particular fruit, then another, then another, 
  and eventually invented fruit as a general concept.  Similarly, one first
  invents one ADT, then another, then another, and eventually a pattern
  begins to emerge which seems to be worthy of its own name.  Thus, I 
  think it more appropriate to simply define abstract classes of types, 
  characterized by the operations applicable to any type in that class.   

From apc@cbnews.ATT.COM (Alan P. Curtis):
> I think the point of truely reusable components is that you cannot, and
> should not diddle!  [...]
> 
> Do you diddle with quad nand gates?
> Do you diddle with the internals of a 68k?
> 
> I didn't think so.

  Exactly.  The objective, I think, is to come up with catalogs of
  reuseable software components just as electrical engineers have
  catalogs of reuseable hardware components.  And for each component,
  a separate listing of different implementations -- the software 
  implementations varying according to whether one operation is O (log n)
  at the expense of another which consequently drops to O (n), etc.,
  and the hardware implementations varying according to temperature
  ranges which will be tolerated, etc.; in this way, we hope to achieve
  similar levels of productivity in *software* engineering. 

  As I see it, the Big Problems are:

    - Capturing the domain knowledge in the first place and encoding
        the functional descriptions into appropriate component interfaces.

    - Enforcing standards of component quality: complete and precise
        specifications along with readable abstracts, and verification 
        of component correctness even under externally parallel conditions.

  Only when we have achieved all this for a reasonably large number of
  domains will we be in a position to claim that software engineering
  is not a contradiction in terms, which (justifiably) is the current 
  position of many in the less-recently-created engineering professions.

  Another extremely important problem is:

    - Exploiting internally parallel processing to achieve very high-speed 
        implementations which externally can be treated as if they were
        sequential implementations which simply happen to run VERY fast. 

  Parallel processing is a complex area, and very error-prone; in my view,
  one of the best possible ways to manage this complexity is to hide that
  complexity within a component specification which can be used as if it 
  were nothing more than a simple sequential component.  At no cost in terms
  of extra programming time, our applications will be able to achieve the
  high responsiveness which can only be achieved through parallel processing,
  certainly a major breakthrough in terms of software technology.  On top of
  this would be the possibility of advanced compiler technology which might
  be able to parallelize even the sequential code lying on top of the 
  already-parallel components.  This of course will interact with the
  corresponding developments in computer networking (e.g., the NECTAR
  backplane, which enables many systems to transfer data across large
  distances at nearly the speed of light) and network operating systems
  (process migration technology) to achieve nearly optimal utilization. 

From: adamsf@cs.rpi.edu (Frank Adams)
>>   [A] short little program can be written to ... add a layer of abstraction;
>
> This is just inheritance via another name.  Isn't it better to have this as
> a language feature instead of an external hack?

   No, because the automatically generated code will eventually be
   rewritten, and there needs to be the separation between specification
   and implementation so that the rewrite will not obsolete lots of code.

   Another negative aspect is that inheritance tends to focus attention
   on the underlying layer of abstraction, instead of the current layer
   of abstraction.  With calls to an underlying abstraction, the focus 
   on how to implement the current abstraction is maintained.
 
From Ralph Johnson:
>>   I don't perceive any need for run-time binding.
> 
> Consider a windowing system.  A big window can contain smaller windows.
> Each window can display itself.  A large window displays itself by displaying
> its smaller windows.  It would have an array of subwindows, and would
> iterate over them, performing the DISPLAY operation on each one.  However,
> since different subwindows display different kinds of things, there must
> be run-time binding.  

   I think not; the "large window" can simply rendezvous with each of its 
   subwindows (an array of tasks) in order to notify them of the redisplay
   requirement.  In turn, the subwindows then rendezvous with application-
   specific tasks as necessary.

   I've done some work with the Telesoft Sunview <-> Ada binding, which 
   approaches it by having you instantiate a generic with the user-supplied 
   procedure to be called whenever the window needs to consult the application
   as to how to handle specific user input, but I think a tasking approach 
   would provide a much cleaner solution.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu