bearophile wrote:
So I'm asking for more info here.
The classes `invariant' can be eliminated by a `debug'-prefix.
-manfred
Walter Bright wrote:
I'm not going to swap them without a compelling demonstration of
its advantages.
If there are advantages, then the specs are wrong, because they do not
define the sequence of execution and an optimizing compiler might put
the calls to conditions and `invariant' into
On 1/20/2012 12:23 AM, Manfred Nowak wrote:
If there are advantages, then the specs are wrong,
I recently fixed the specs to define the sequence.
On Fri, 20 Jan 2012 00:01:40 -0500, Walter Bright
newshou...@digitalmars.com wrote:
On 1/19/2012 8:19 PM, Steven Schveighoffer wrote:
If they are related, yes it does give you more information. The out
condition
might not check the class data directly, but the error which caused the
Walter Bright wrote:
I recently fixed the specs to define the sequence.
Then the Status Quo holds. One more remark:
if the intention still is, that contracts are to be seen as an
executable description of at least parts of the design, then the
current specification of the language does not
On 1/20/2012 10:42 AM, Manfred Nowak wrote:
if the intention still is, that contracts are to be seen as an
executable description of at least parts of the design, then the
current specification of the language does not give any control over
those contracts to the designers.
This is because the
Walter has recently closed a bug report without fixing it and without an
answer, it's about contract based programming:
http://d.puremagic.com/issues/show_bug.cgi?id=5024
So I'm asking for more info here.
As reference I use this little program (I have improved it a bit compared to
the one
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is better
(or maybe why it's just equally good). Thank you :-)
Honestly, I don't think that the order is all that critical, since all of the
same assertions are run in
On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is better
(or maybe why it's just equally good). Thank you :-)
Honestly, I don't think that the order is all that critical,
Walter:
My reasoning is it (1) doesn't make any difference and (2) it's always been
like
that - and if it did make a difference, it would break 10 years of existing
code.
In the second code example I've shown I receive an assert error in the wrong
place. If a method is buggy, and its
On Thu, 19 Jan 2012 20:38:05 -0500, Walter Bright
newshou...@digitalmars.com wrote:
On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is
better
(or maybe why it's just
On 1/19/2012 6:37 PM, Steven Schveighoffer wrote:
I have to disagree on some level with (1). It might not make a difference in
determining there is a bug, but it makes a difference because failing in the
out-condition gives you more information, even if the invariant is broken. It
tells you
On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is better
(or maybe why it's just equally good). Thank you :-)
Honestly, I don't think that the order is all that critical,
On Thu, 19 Jan 2012 22:31:08 -0500, Walter Bright
newshou...@digitalmars.com wrote:
On 1/19/2012 6:37 PM, Steven Schveighoffer wrote:
I have to disagree on some level with (1). It might not make a
difference in
determining there is a bug, but it makes a difference because failing
in the
On Thursday, January 19, 2012 23:19:02 Steven Schveighoffer wrote:
Imagine you have 1000 lines of code that call 50 or so
different methods on a class. Any one of those calls in any one of those
methods could cause an invariant failure. But only one method call can
cause a specific out
On Thu, 19 Jan 2012 22:33:40 -0500, Davidson Corry
davidsonco...@comcast.net wrote:
On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is
better
(or maybe why it's just
On Thu, 19 Jan 2012 23:24:59 -0500, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, January 19, 2012 23:19:02 Steven Schveighoffer wrote:
Imagine you have 1000 lines of code that call 50 or so
different methods on a class. Any one of those calls in any one of
those
methods could
On 1/19/2012 8:19 PM, Steven Schveighoffer wrote:
If they are related, yes it does give you more information. The out condition
might not check the class data directly, but the error which caused the
invariant to fail could have also caused the out-condition to fail. It's
inconsequential to the
On Thursday, January 19, 2012 21:01:40 Walter Bright wrote:
Invariants and conditions are allowed to be impure so they can do things
like logging.
Yeah, but if they're modifying state, they're doing something which is
essentially invalid, so from the standpoint of breaking code, I don't think
On 1/19/2012 9:14 PM, Jonathan M Davis wrote:
Yeah, but if they're modifying state, they're doing something which is
essentially invalid,
Yup, so arguing for which order the state changes should come in is also
invalid.
so from the standpoint of breaking code, I don't think
that swapping
On Thursday, January 19, 2012 21:31:14 Walter Bright wrote:
I'm not going to swap them without a compelling demonstration of its
advantages. Not breaking much code is not an argument for changing current
behavior.
I'm not saying that it is. I'm just saying that breaking code should not be a
2012/1/20 bearophile bearophileh...@lycos.com:
Walter has recently closed a bug report without fixing it and without an
answer, it's about contract based programming:
http://d.puremagic.com/issues/show_bug.cgi?id=5024
So I'm asking for more info here.
As reference I use this little program
22 matches
Mail list logo
