Comments on: Contract Programming in D http://www.hans-eric.com/2007/08/27/contract-programming-in-d/ Hans-Eric Grönlund on software development Thu, 24 Jul 2008 10:24:06 +0000 http://wordpress.org/?v=2.5.1 By: The Future of D is Functional http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-5580 The Future of D is Functional Wed, 16 Apr 2008 10:33:49 +0000 http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-5580 [...] people think D suffers from such a feature creep. To some degree I can agree. D has features that are unlikely to become widespread, but most of them are aligned towards a common goal. That goal is bringing productivity to the [...] [...] people think D suffers from such a feature creep. To some degree I can agree. D has features that are unlikely to become widespread, but most of them are aligned towards a common goal. That goal is bringing productivity to the [...]

]]> By: www.hans-eric.com » Blog Archive » Is the Contract Programming of D broken? http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-13 www.hans-eric.com » Blog Archive » Is the Contract Programming of D broken? Wed, 29 Aug 2007 10:57:05 +0000 http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-13 [...] www.hans-eric.com « Contract Programming in D [...] [...] http://www.hans-eric.com « Contract Programming in D [...]

]]> By: Hans-Eric http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-12 Hans-Eric Wed, 29 Aug 2007 09:15:56 +0000 http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-12 wekempf: I meant the entire clause, not the individual conditions. I wasn't clear in my post and I'm glad you clarified it. Stay tuned, I'm currently investigating the behavior of D:s contracts in an override scenario. I hope to post the results and the code later today. wekempf: I meant the entire clause, not the individual conditions. I wasn’t clear in my post and I’m glad you clarified it.

Stay tuned, I’m currently investigating the behavior of D:s contracts in an override scenario. I hope to post the results and the code later today.

]]> By: wekempf http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-11 wekempf Tue, 28 Aug 2007 13:48:20 +0000 http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-11 Preconditions may be loosened, while postconditions may be tightened. The individual conditions aren't ORed, it's the entire in clause that's ORed between super and sub classes for a particular method. I've not used D, but this is the same concept used by other languages that support DbC. It would be interesting to see code that you think exhibits different behavior. DbC doesn't fully replace defensive coding. There's a reason why you still have the assert(). You should really be using both, since assert() can't do everything that DbC can do, and vice versa. However, if all of your code is properly contracted, you'll find fewer instances where you need an assert(). Preconditions may be loosened, while postconditions may be tightened. The individual conditions aren’t ORed, it’s the entire in clause that’s ORed between super and sub classes for a particular method. I’ve not used D, but this is the same concept used by other languages that support DbC. It would be interesting to see code that you think exhibits different behavior.

DbC doesn’t fully replace defensive coding. There’s a reason why you still have the assert(). You should really be using both, since assert() can’t do everything that DbC can do, and vice versa. However, if all of your code is properly contracted, you’ll find fewer instances where you need an assert().

]]> By: Hans-Eric http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-10 Hans-Eric Tue, 28 Aug 2007 07:55:03 +0000 http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-10 You definitely have a point there. In my experience, the need of documentation varies depending on situation. If a defensive code is solely internal, testing class internal, non-published implementation specific code, then there is little need for documentation and specific tests. On the other hand, if it is protecting from external misuse, then you need to document and test your assumptions. In those cases I tend to make as little assumptions as possible. Contract Programming tends to be self documenting, and tools can be made to help extracting information from them. That is an advantage DbC has over the informal defensive coding. You definitely have a point there.
In my experience, the need of documentation varies depending on situation. If a defensive code is solely internal, testing class internal, non-published implementation specific code, then there is little need for documentation and specific tests. On the other hand, if it is protecting from external misuse, then you need to document and test your assumptions. In those cases I tend to make as little assumptions as possible.
Contract Programming tends to be self documenting, and tools can be made to help extracting information from them. That is an advantage DbC has over the informal defensive coding.

]]> By: Mike Kaufman http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-9 Mike Kaufman Mon, 27 Aug 2007 21:10:42 +0000 http://www.hans-eric.com/2007/08/27/contract-programming-in-d/#comment-9 I think another potential issue is how to document the rules/contracts, and how to check they are present and as intended. I'm currently working in Java, and code defensively - and the checks end up being documented in the Javadoc, in natural language. And they need tests to prove they behave as intended and documented (though I guess many wouldn't bother). With "contract" programming, because the conditions are more formally identified and defined, I'd expect that a lot of that should disappear or be handled automatically (or at least benefit from being clearly separate and more codified). I think another potential issue is how to document the rules/contracts, and how to check they are present and as intended.

I’m currently working in Java, and code defensively - and the checks end up being documented in the Javadoc, in natural language. And they need tests to prove they behave as intended and documented (though I guess many wouldn’t bother).

With “contract” programming, because the conditions are more formally identified and defined, I’d expect that a lot of that should disappear or be handled automatically (or at least benefit from being clearly separate and more codified).

]]>