From MARCUS_A_SMITH@HP-Boise-om8.om.hp.com  Wed Oct  1 09:20:18 1997

     Hi Anne,
     
       I don't know how much you know about Eiffel (the OO language) and a 
     theory called "Design By Contract" (DBC), but I'd like to pitch an 
     idea.
     
       In my project group, we have been looking at more formal ways to 
     test the integrity of components (OO objects) and have found Eiffel's 
     ability to provide DBC priceless.
     
       DBC is related to PRE/POST conditions in that they both give 
     programmers the means to specify entry and exit conditions.  DBC 
     differs in that the specification is not in the form of a comment, 
     rather it is 100% executable, as native instructions.  A quick example 
     of the Eiffel function put(x:G) will demonstrate the difference.  Put 
     just places the argument on a stack.
     
     feature {NONE}
     
       -- Put places x on top of the stack.
       -- PRE:  The stack cannot be full.  x cannot be void
       -- POST: The stack is not empty.  Top most element on stack
       -- is x.  New element count is old element count + 1.
       put(x:G) is
          require
             not full
     
          ........ <do stuff!>
     
          ensure
             stack.empty = FALSE
             stack.top = x
             stack.count = old stack.count + 1
     
          end
     
     
       What you see in the function header comments is typical of PRE/POST 
     conditions.  They are effective in only warning documentation readers 
     of invalid conditions.  They do nothing at run-time to assure the 
     validity of the arguments and/or exit states.
     
       Run-time checking is a big deal because many developers do not read 
     comments.  Furthermore, there are no good mechanisms to keep code and 
     comments together, so the likelyhood of them becomming de-attached is 
     quite high.  This assures medium to large scale project teams can (and 
     will) successfully integrate their code with no assumptions (because 
     bad assumptions are flagged).
     
       This concept has been in use and working well in my project team for 
     about 1.5 years.  I've been thinking of providing an analagous way of 
     doing DBC in Java, since DBC was ripped out of Java v0.9 (according to 
     James Gossling).  It seems like our CSCI322 project could benefit 
     greatly from this concept.  Unfortunately, there does not seem to be 
     an easy way to pull it off in Java.
     
       This is why I'm writting this, because I think developing a class, 
     that would throw a new DBC exception would be valuable.  I started 
     thinking about this as I was developing my ADT for Thursday.  It does 
     not seem trivial, but seems bounded.  Here is how I envision the 
     function put written in Java DBC
     
     void put(StackElement x)
     {
        // Require section
        try {
        Require.check(stack.full == false);
        } catch (DBCException e)
        {
           // Printout the stack, and perhaps other stuff, then error out.
        }
     
        .........<do stuff!>
     
        try {
        Ensure.check(stack.empty == false);
        Ensure.check(stack.top == x);
        Ensure.check(stack.count == (stack.count - 1));
        }
        catch (DBCException e)
        {
           // Printout the stack, and perhaps other stuff, then error out.
        }
     
     }  // End of put()
     
     
     Requre and Ensure are Java classes, implementing the Throwable 
     interface.  They would throw a new exception, derived off 
     java.lang.Exception.  After development, the Require and Ensure 
     classes could switch states to not check arguments...that is...act as 
     a bypass.  This would increase preformance after exhaustive checking 
     is no longer needed.  This is all I have for now.  I'll think about 
     this some more.
     
     What do you think?
     
     Thanks,
     
     Marcus Smith