A difference in terminology I would guess:

1) Assumptions to me are things you unconsciously assume are true 
without any justification.  Such as assuming that the caller will never 
provide a negative index (a bad assumption).
2) Design constraints such as preconditions, postconditions, and type 
limits are just that, constraints.  The constraints under which a piece 
of code is DESIGNED to operate are very different from the assumptions 
that go unstated.  The constraints a system or block of code was 
designed to operate under should clearly be document when at all 
possible, and some can be inferred from the rest of the system or from 
usage of the code.

My comments are based on the fact that items in list 1 seem to always 
take far longer to ferret out than those in list 2.

Michael



On Oct 18, 2004, at 7:58 PM, Richard A. O'Keefe wrote:

> Michael Latta <lattam at mac.com> wrote:
> 	While it would be nice to get a list of assumptions for a piece of
> 	code, it is never going to happen.
>
> With respect, this is far too strongly stated.
> Yes, you are never going to get a COMPLETE list.
> But it would be manifest nonsense to say that you are never going to
> get a USEFUL list.  This is precisely what preconditions are.
>
> 	The author of the code is not even
> 	in a position in most cases to enumerate them
>
> Again, I must VERY STRONGLY disagree.  The author *DOES* know the
> assumptions he consciously made to justify the code.  Admittedly
> he doesn't know the assumptions he made unconsciouly, but that's
> not at all the point.  The preconditions he DID consciously use in
> deriving the code are important to know, and he is not only in
> a position to enumerate them, but he is in a position to enumerate
> them before he starts to write the code, and he is in a far far
> better position to do so than anyone else will ever be.
>
> 	It would be better to have the tools somehow help us visualize
> 	or annotate the code with the actual pre/post conditions that can be
> 	inferred from the system being worked on.
>
> I am sorry, but this makes no sense to me.  You seem to be saying that
> it is so impossible for people to write down their thoughts at the time
> they design the code that it is better to wait for amazing software 
> tools
> that can reconstruct their thinking after the event?
>
> Software tools have come a _long_ way.  I'm amazed at some of the 
> things
> they can do.  But reconstructing correct preconditions and 
> postconditions
> from incorrect code?
>
> 	Then if you write your test cases first (like XP suggests), the
> 	system will help you know what is going on.
>
> As I thought I made clear, I didn't WANT to know "what is going on".
> That I could figure out for myself without any fancy tools.
> What I needed to know, and eventually could not figure out, was
> "what is SUPPOSED to be going on"?  "Why did the original programmer
> THINK it was right?"  "What properties precisely is the output supposed
> to have?"
>
> Do I need to point out the futility of relying _only_ on test cases?
> Had there been a test case that revealed the problem, the bug would
> have been fixed long before I came on the scene.  How are these Utopian
> tools supposed to infer correct presuppositions from non-existent test
> cases?  The bug only came to light after the software had correctly
> processed millions of large real cases, about 4 years after it was 
> written.
>
>