From: Hugh Sasse <hgs@...>
Date: 2006-08-03T02:25:00+09:00
Subject: Re: doc patch: weakref.

On Thu, 3 Aug 2006, mathew wrote:

> Hugh Sasse wrote:
> > OK, you've convinced me that this leads to broken encapsulation.
> > I'll look at this further.  It is probably best ensure the contract
> > is specified by unit tests though, but the creation of a complete
> > test set has been another topic recently, so I'll say no more here..
> 
> I've explained before that unit tests are not a *specification* of anything.
> They may *test* a specification, but in general it is not possible to convert
> a specification into a set of unit tests without losing information.

They express intent in a machine-useable way.  They may be incomplete,
but the advantage they have over docs is that in TDD they get fixed.

I should have put "specified as much as possible by unit tests". The 
incompleteness of them has been expressed before (maybe it was by you,
but I forget), but I think the concept of "satisficing" is useful here.  

> 
> For example, for any finite set of unit tests that attempt to specify the
> behavior of +, I can define a function f() that passes all those tests, but
> behaves differently to +, and code that relies on the f() behavior.

Yes.  But for any finite amount of documentation, you can find someone
who will misunderstand it.  Hence the original Murphy's law.  In agile
thinking code beats docs.  [I'm not trying to reduce software construction
to "rock, paper, scissors", just to say that what can be automated
should be.]
> 
> Denotational semantics would allow an algorithmic specification of APIs, but

Hence functional programming, but what would one use to check that
the maths was correct? I think it's "turtles all the way down", but
at least with unit tests they are the same species, so if you need
to replace code you can replace tests without a knowledge of Pi
calculus, etc. I found the Wikipedia page about denotational
semantics to be less than light reading :-)

> Ruby is not suitable for application of denotational semantics because of
> features like variables. (That is, unless there's been some major breakthrough
> in formal semantics of programming languages in the last 10 years that I've
> missed hearing about.)

The Wikipedia page suggests many such things including delayed calculations,
logic programming, networked systems have been addressed.
> 
> 
> mathew
> 
> 
        Hugh