On 10/13/2011 08:25 PM, Davidson Corry wrote:
On 10/13/2011 10:57 AM, bearophile wrote:
Jonathan M Davis:
I don't recall him ever saying anything about contract programming in
D being a failure in any way.
He said unittesting has changed the way you write code and has
significantly decreased bugs count, while he was not equally happy
about contract programming. From several things he has said, he looks
disappointed by D contract programming.
IIRC, old was rejected because it added extra complication for little
value.
It add some complexity, but I can't agree that it adds little value...
And I don't remember it being rejected, I just remember the discussion
stopped, like a river dying and drying up in a desert.
Implementing DbC is tricky, and 'old' particularly so. For instance,
what if the condition whose state-at-entry you want to inspect at exit
happens to reside in a base class implemented in a different module?
(Note that D supports separate compilation while Eiffel doesn't.)
'unittest' is a major win in D, and may as a practical matter alleviate
much of the need for other kinds of testing. But...
[opinion]
...unit testing and DbC are *orthogonal* or at least complementary, in
my view. Conceptually, unit testing tests a class or object from the
*outside* of its public boundaries, while DbC tests the object from
*within*. They catch different classes (sic) of implementation error.
Some bugs may be caught both ways, which is great. But some might slip
by one, only to be caught by the other.
Like any technique (including unit testing) DbC takes practice to learn
how to do well, and it is new to most programmers even 25 years after
Meyer brought it to the masses. There's a bootstrapping problem here: if
DbC isn't fully implemented, it's not as useful. If it's not useful,
programmers won't use it. If they don't use it, compiler implementers
won't improve the implementation. And so on.
Look, Walters are in scarce supply, and I don't want to jog their elbows
on priorities -- they come up with so much other cool stuff! I'm just
saying, 'old' would be nice.
[/opinion]
-- Davidson
I don't agree that 'old' is very difficult to implement. Just evaluate
what is inside the 'old' before you enter the in contract, store
somewhere, maybe in hidden local variables, and make the data available
in the out contract. Eiffel's 'old' does not do more than that.
(but perhaps there are implementation details in DMD that make this more
difficult than necessary. I don't know.)
