Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels!xtbjh From: xtbjh@levels.sait.edu.au Newsgroups: comp.software-eng Subject: Re: Tolerance (was Re: Reusability considered harmful??(!!)) Message-ID: <15864.27aff4f9@levels.sait.edu.au> Date: 6 Feb 91 12:22:17 GMT References: <1401@ucl-cs.uucp> <27A9B451.48BF@tct.uucp> <15863.27ad36b6@levels.sait.edu.au> <777@caslon.cs.arizona.edu> <785@caslon.cs.arizona.edu> Organization: Sth Australian Inst of Technology Lines: 48 In article <785@caslon.cs.arizona.edu>, dave@cs.arizona.edu (Dave P. Schaumann) writes: > [...] But my question was in the context of code re-use. > How could you say something like, "well, I really need a stack, but I'll > settle for something sort of stacky"? Will we see code like this in the > future: > > assert( stackyness(re_used_type) > 0.9 ) ; /* stackyness(a real stack)=1.0 */ > > I can't see how the "tolerence paradigm" could possibly lead to a reasonable > means of code re-use. Every specification has areas that are black and white and areas that are shades of gray. There isn't enough time to specify everything; you can only specify the most important things and hope that the remainder is tolerable. For example, how long will a particular circuit board run before something on it breaks down? Usually your only "specification" in such a case is the manufacturer's warranty (or in extreme cases the consumer protection laws). The stack example above is typical: you wanted the operation of the stack to be very reliable, but you didn't specify: - how quickly you wanted the stack to operate, and - how the stack would perform if one of its resources was exhausted. You might not accept a stack implementation that took 1 second to execute a push or a pop, or a stack that had a limit of 2 elements. Any implementation of a stack will have restrictions; your design, specification and testing are intended to ensure that the "stackyness" of the final implementation is sufficiently high. The nub of the tolerance issue is that you are tricked by the languages you use into believing that there is an infinite amount of some resource (most typically CPU and/or memory). This is because these are mostly irrelevant to the interface that you are building; they mostly remain hidden by the implementation. Yet when you look to reuse a component, these details are often significant. Another problem is that the interface itself is often shaped by the underlying architecture of the machine. The machine in this case refers mostly to the programming language; other items such as CPU and memory are involved at a lesser level. > Dave Schaumann | And then -- what then? Then, future... > dave@cs.arizona.edu | -Weather Report -- Brenton Hoff (behoffski) xtbjh@levels.sait.edu.au Transponder Australia My opinions are mine (and they're really weird).