Did D2 ever implement the Eiffel "old" construct? I do not see it mentioned in "The D Programming Language", and the only reference I can find in the newsgroup is a short discussion in June of 2007 that seemed to go nowhere.

If not, has anyone developed a reasonable workaround? Thanks.

-- Davidson

 ============

Brief description: in Eiffel,
      old expr
can be used in post-conditions, and evaluates to the value of
      expr
as of entry to the function. It's useful to help verify that the function has done what it was supposed to, but especially powerful when used in classes because it complements invariant:  invariant tests what has *not* varied (duh),    old expr   helps test what *has* varied to ensure that it has varied *correctly*.

For example, the .Add() method of a Container class might in its postcondition assert
       assert( count == old count + 1 )
to ensure that *exactly* one element got added, no more and no less

Davidson Corry:

> Did D2 ever implement the Eiffel "old" construct?

At the moment there no prestate in D. I agree that prestate is an important sub-feature of contract programming. It was discussed two or three times, but the discussions didn't produce actual results. I think it was not implemented because I think Walter thinks D contract programming is a half failure (I don't agree on this) and because implementing the prestate is a bit tricky. I suggest to ask about this in the main D newsgroup, and show two use cases too. I think if enough people show use cases, and someone writes a good enough pull request for DMD, it will be added to D/DMD.


> If not, has anyone developed a reasonable workaround? Thanks.

In classes inside a debug I have defined handmade "ghost attributes":

debug {
  int ghost1, ghost2;
}

I use them to manually store the prestate that later I want to verify. This is not a very good solution...

Bye,
bearophile

On Thursday, October 13, 2011 05:35:52 bearophile wrote:
> Davidson Corry:
> > Did D2 ever implement the Eiffel "old" construct?
> 
> At the moment there no prestate in D. I agree that prestate is an important sub-feature of contract programming. It was discussed two or three times, but the discussions didn't produce actual results. I think it was not implemented because I think Walter thinks D contract programming is a half failure (I don't agree on this) and because implementing the prestate is a bit tricky.

I don't recall him ever saying anything about contract programming in D being a failure in any way. IIRC, old was rejected because it added extra complication for little value.

- Jonathan M Davis

On Thu, 13 Oct 2011 09:18:46 -0700, Jonathan M Davis wrote:

> On Thursday, October 13, 2011 05:35:52 bearophile wrote:
>> Davidson Corry:
>> > Did D2 ever implement the Eiffel "old" construct?
>> 
>> At the moment there no prestate in D. I agree that prestate is an important sub-feature of contract programming. It was discussed two or three times, but the discussions didn't produce actual results. I think it was not implemented because I think Walter thinks D contract programming is a half failure (I don't agree on this) and because implementing the prestate is a bit tricky.
> 
> I don't recall him ever saying anything about contract programming in D being a failure in any way.

He had mentioned that at some point the implementation of contract programming had serious bugs but nobody had complained.

> IIRC, old was rejected because it added
> extra complication for little value.

Yes, there were technical difficulties in making the stack frame at the call point available to the stack frame at the exit point.

> 
> - Jonathan M Davis

Ali

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 why 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, this is a mistake. The prestate increases significantly the usefulness of contract programming. And I don't remember it being rejected, I just remember the discussion stopped, like a river dying and drying up in a desert. Do you have a link of a post where it was rejected? I think there is an enhancement request about prestate in Bugzilla, and it is open still. Before actually rejecting this feature, it will need one more good discussion in the main D newsgroup.

----------------------

Ali Çehreli:

> He had mentioned that at some point the implementation of contract programming had serious bugs but nobody had complained.

I am not sure, but I think I did complain about some of those bugs. I have some old bug reports in Bugzilla about contract programming that are open still.

Bye,
bearophile

On Thursday, October 13, 2011 10:57 bearophile wrote:
> Jonathan M Davis:
> > 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, this is a mistake. The prestate increases significantly the usefulness of contract programming. And I don't remember it being rejected, I just remember the discussion stopped, like a river dying and drying up in a desert. Do you have a link of a post where it was rejected? I think there is an enhancement request about prestate in Bugzilla, and it is open still. Before actually rejecting this feature, it will need one more good discussion in the main D newsgroup.

I'd have to go digging, but from what I recall, it was pretty clear that it wasn't happening. But since it's not a feature that I care about at all, it's not something that I've tracked particularly closely.

- Jonathan M Davis

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

Jonathan M Davis:

> I'd have to go digging, but from what I recall, it was pretty clear that it wasn't happening.

I see. And sorry for the tone of my last answer. Don't worry if you don't have the time to find it.

Bye,
bearophile

On 10/13/2011 07:14 PM, Ali Çehreli wrote:
> On Thu, 13 Oct 2011 09:18:46 -0700, Jonathan M Davis wrote:
>
>> On Thursday, October 13, 2011 05:35:52 bearophile wrote:
>>> Davidson Corry:
>>>> Did D2 ever implement the Eiffel "old" construct?
>>>
>>> At the moment there no prestate in D. I agree that prestate is an
>>> important sub-feature of contract programming. It was discussed two or
>>> three times, but the discussions didn't produce actual results. I think
>>> it was not implemented because I think Walter thinks D contract
>>> programming is a half failure (I don't agree on this) and because
>>> implementing the prestate is a bit tricky.
>>
>> I don't recall him ever saying anything about contract programming in D
>> being a failure in any way.
>
> He had mentioned that at some point the implementation of contract
> programming had serious bugs but nobody had complained.
>
>> IIRC, old was rejected because it added
>> extra complication for little value.
>
> Yes, there were technical difficulties in making the stack frame at the
> call point available to the stack frame at the exit point.
>

Why would that be required?

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.)