Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!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: What should a component library loo
Message-ID: <7189@hubcap.clemson.edu>
Date: 26 Nov 89 20:02:12 GMT
References: <130200023@p.cs.uiuc.edu>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 38

From article <130200023@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu:
> I am strongly in favor of separating specification from implementation
> as much as possible.  [...] My observation is that, except for general 
> purpose data structures, there doesn't seem to be much need for a component
> to have a variety of implementations that vary in performance characteristics.
> [...] I think of "specification" as defining the behavior of a component

   Okay, let's talk about that.  Suppose that we have a application entity
   whose behavior is defined by a specification.  We must now be very
   careful with respect to what we mean by this.  Traditionally, this has
   meant that all behavior is defined EXCEPT performance behavior such as
   time and space consumption (tradeoffs) among the various operations.  

   If we define a specification such that it completely specifies the behavior
   of a component, UP TO AND INCLUDING component performance characteristics, 
   then there is clearly little need to have a variety of implementations.

   Assume otherwise, i.e., that the term "specification" does not include
   performance characteristics.  Consider an application entity -- not a
   general-purpose data structure, but an object associated with the
   application domain.  Different applications having different performance
   interests may well emphasize different operations over that application
   entity.  Surely we would not wish to introduce redundancy by having  
   several different definitions of the same object; we would instead wish
   to factor out the commonality of the shared specification.  Nor would we
   wish to have a single definition that has to be rewritten (at great cost)
   every time it is used or every time we wish to regenerate a particular
   application.  Furthermore, it may well be the case that we wish to have,
   within a single application, particular instances of an object whose 
   performance characteristics differ but which are otherwise interchangeable
   (e.g., as parameters to a subprogram which requires that type of object).

   If we accept the basic premise that performance characteristics are
   an important consideration, then I think it follows that there is a
   fundamental need to express the existence of different implementations.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu