Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!Teknowledge.COM!unix!hplabs!hp-sdd!ncr-sd!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: <7273@hubcap.clemson.edu>
Date: 1 Dec 89 03:42:17 GMT
References: <71800003@m.cs.uiuc.edu>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 36

From kamin@m.cs.uiuc.edu (Sam Kamin), who clarifies things considerably:
> we need a specification that not only says what a method m does, 
> but says how your redefinition of some other methods will alter 
> what m does.  [...] In principle, this is just an "abstract, 
> functional" spec., but in practice it is a much more complicated thing.
> [...] This has some bearing also on the current argument about multiple
> implementations of a single spec.  I think Ralph is saying that in his
> experience in Smalltalk, this doesn't happen much.  However, what *does*
> happen a lot is that a class is inherited and modified (by subclassing).
> In other words, in this context, one has a spec. (if at all), not in
> order to give multiple implementations that vary in *performance*, but
> rather to give multiple implementations that vary in *semantics*.  

   Thank you, Sam!!!  

   OK, now that we have established what it is we are discussing... :-)

   I for one have never seen ANY discussion of this type of specification
   anywhere, although it is intuitively obvious that o-o languages will
   require this sort of "specification", and it would certainly appear 
   to be high time that somebody HELD such a discussion.  

   Has any work been done regarding the ins and outs of writing & using
   these specifications?  It might be interesting to see a few examples
   which present the general idea and demonstrate how complications can
   arise.  Also, a few comments regarding the integration of this new type
   of specification into the traditional framework would be interesting...

   Since the *.uiuc.edu folks proposed this departure from the traditional
   specification/implementation paradigm, hopefully they are in a position
   to open the discussion.  If we can get a good handle on this type of
   specification, then I think we will be well on the way to integrating
   o-o techniques and components into software engineering environments.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu