www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Invariants for methods

reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


I don't think they have contracts in interfaces, which is where most difficulty
lies.<



There is some discussion about this topic at page 11 here:
http://research.microsoft.com/en-us/projects/contracts/userdoc.pdf



At any rate, it's not that we can't do it, it was just a large effort that we
decided to postpone.<



Postponing its solution (to D3, if needed) is good.



Is there anything wrong with the workaround I suggested?<



We have had a discussion like this many times, about unittests, ranged
integers, nonull references, etc, so probably we think about languages in
different ways.

Your workaround is an intelligent trick, I was not able to invent it, and it's
a solution better than the one I have used to solve it (ghost fields in
debug{}).

In my opinion in a language you must not need to use intelligent tricks to
solve basic problems (and referring to the old state is one of the important
parts of DbC).

Bye,
bearophile
Nov 18 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/18/10 1:07 PM, bearophile wrote:

 Andrei:


 I don't think they have contracts in interfaces, which is where most
difficulty lies.<



 There is some discussion about this topic at page 11 here:
 http://research.microsoft.com/en-us/projects/contracts/userdoc.pdf



 At any rate, it's not that we can't do it, it was just a large effort that we
decided to postpone.<



 Postponing its solution (to D3, if needed) is good.



 Is there anything wrong with the workaround I suggested?<



 We have had a discussion like this many times, about unittests, ranged
integers, nonull references, etc, so probably we think about languages in
different ways.

 Your workaround is an intelligent trick, I was not able to invent it, and it's
a solution better than the one I have used to solve it (ghost fields in
debug{}).

 In my opinion in a language you must not need to use intelligent tricks to
solve basic problems (and referring to the old state is one of the important
parts of DbC).

 Bye,
 bearophile



I don't see anything remotely clever in the solution I suggested. At 
some point it's worth starting to use the language to devise solutions 
to problems instead of inventing a new feature for any problem that 
comes about.

Andrei
Nov 18 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 I don't see anything remotely clever in the solution I suggested.



I am not clever enough...



 At some point it's worth starting to use the language to devise solutions 
 to problems instead of inventing a new feature for any problem that 
 comes about.



That was not a new unexpected problem, it was an example of missing brick of
the D DbC. It's like you remove preconditions: then something is missing in the
frame. Loop invariants and loop variants are minor feature of DbC and they
probably may be spared in D (and when necessary loop invariants may be
implemented manually with a call to a pure function), but prestate access is
something I/you need often when you want to use DbC, it's not there in Eiffel
and C# for sport.

Your view of how to design a language is probably different from mine.

Bye,
bearophile
Nov 18 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/18/10 2:02 PM, bearophile wrote:

 Andrei:


 I don't see anything remotely clever in the solution I suggested.



 I am not clever enough...



This would be more credible if this were indeed a matter of being 
clever. It is a basic juxtaposition of ubiquitous features.


 At some point it's worth starting to use the language to devise solutions
 to problems instead of inventing a new feature for any problem that
 comes about.



 That was not a new unexpected problem, it was an example of missing



is missing in the frame. Loop invariants and loop variants are minor
feature of DbC and they probably may be spared in D (and when necessary
loop invariants may be implemented manually with a call to a pure
function), but prestate access is something I/you need often when you
want to use DbC, it's not there in Eiffel and C# for sport.

 Your view of how to design a language is probably different from mine.



I allowed myself to reflect a bit on the "moving average", so to say, of 
your posts, than on this particular one. That moving average reveals a 
trigger happiness about adding features instead of using existing 
features. It also reveals a consistent effort to find what other 
languages do better than D, which is good. What is missing, however, is 
taking advantage of the many things that D _does_ do well (and better 
than various other languages).

It's not impossible our views on language design differ, but that's 
nothing odd as the process and appreciating the results are highly 
subjective.


Andrei
Nov 18 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/18/10 1:07 PM, bearophile wrote:

 Andrei:


 I don't think they have contracts in interfaces, which is where most
difficulty lies.<



 There is some discussion about this topic at page 11 here:
 http://research.microsoft.com/en-us/projects/contracts/userdoc.pdf



That approach is essentially a workaround for a problem that I consider 
crucial (interfaces must be able to specify contracts) that D solves 
properly.

Andrei
Nov 18 2010