Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!elephant.cis.ohio-state.edu!weide
From: weide@elephant.cis.ohio-state.edu (Bruce Weide)
Newsgroups: comp.software-eng
Subject: Re: Reuse, Tolerance, and Tradeoffs  (was Re: Tolerance)
Message-ID: <88102@tut.cis.ohio-state.edu>
Date: 7 Feb 91 15:46:03 GMT
References: <1401@ucl-cs.uucp> <27A9B451.48BF@tct.uucp> <785@caslon.cs.arizona.edu> <11803@pt.cs.cmu.edu>
Sender: news@tut.cis.ohio-state.edu
Reply-To: Bruce Weide <weide@cis.ohio-state.edu>
Organization: Ohio State University Computer and Information Science
Lines: 43

In article <11803@pt.cs.cmu.edu> cwk@ORCRIST.GANDALF.CS.CMU.EDU (Charles Krueger) writes:

>With your stack example, I can imagine some flexibility in the stack
>semantics, based on tradeoffs with other constraints.  For example, maybe
>in the "pure" definition of a stack, an error is generated when you try to
>pop an empty stack.  However, in my application I can guarantee that an
>empty stack will never be popped, so I don't want to pay the overhead of
>checking for an empty stack.  By omitting this check, the artifact is no
>longer a pure stack, but just sort of stacky.
>
>The key to making this work, of course, is to keep the tolerance and the
>variability in the artifacts well defined.  The person reusing the
>artifact must clearly know what can be varied and the effect on the
>semantics.  Abstraction is the key to presenting this information to the
>reuser.  It is a hard problem.

Charles, given the second paragraph above (with which I agree if I
understand it) I can't see how you draw the conclusion of the first
one.  In what sense is a stack design, in which no particular error is
generated when an empty stack is popped, no longer a "pure stack"?  As
you point out, this is the RIGHT way to design a most-reusable stack
component.  If some client wants an error message upon popping an
empty stack, he/she can layer a "defensive stack" design on top of
yours.  That way the rest of us don't have to pay for unnecessary
tests for emptiness.  (By the way, Bertrand Meyer and our group have
been saying this for a long time, but most people still don't buy it.
I'm not sure why.)

Maybe this just illustrates the difficulty with ambiguous natural
language descriptions of components.  Charles thinks "pure stack"
means one thing, I think it means something else.  Sheesh, if we can't
even agree on what STACKS are, how likely is it that we will agree on
what more complex components should act like, just from their names?
Guess we'd better consider writing some specifications for these
things...

This reminds me of a paper we got back recently.  One of the reviewers
claimed that our formal specification of a stack component was "wrong"
because it didn't include any a priori bound on how many elements a
stack could contain :-).  Fortunately, the editor did not pay much
attention to this comment.

	-Bruce