 Findler's Contract Flaw Analysis and Eiffel
started 12/16/2002; 9:53:40 AM - last post 12/17/2002; 1:16:16 PM
|
|
Brent Fulgham - Findler's Contract Flaw Analysis and Eiffel 
12/16/2002; 9:53:40 AM (reads: 333, responses: 5)
|
|
|
Findler and Felleisen wrote a great set of papers related to Design By Contract, and some flaws in the way DbC is currently implemented in many tools (yes, including Eiffel).
Since Googling around did not reveal any discussion of these topics in the Eiffel community, I posted a note to the SmartEiffel mailing list, which prompted an interesting discussion of the matter.
Several lucid and reasoned replies were generated, and a short thread in comp.lang.eiffel was started.
Bottom line: "Yes, Findler has identified a flaw in blame assignment, but for knowledgable Eiffel users this is not a problem."
... But I thought DbC was designed to help the not-so-expert user.
Hopefully, someone will modify SmartEiffel to incorporate the additional blame logic. It would be interesting to see if the enhanced reporting has a positive impact on newer Eiffel users' code.
|
|
Ehud Lamm - Re: Findler's Contract Flaw Analysis and Eiffel
12/17/2002; 3:46:47 AM (reads: 337, responses: 0)
|
|
|
Well, the Eiffel syntax hides the problem discussed by Findler. Classes must be declared in such a way that their contracts are LSP compatible. Meyer calls this a 'low tech solution' - but, of course, it is not really a solution.
|
|
Brent Fulgham - Re: Findler's Contract Flaw Analysis and Eiffel
12/17/2002; 9:47:49 AM (reads: 300, responses: 1)
|
|
|
Well, it doesn't seem good enough to me. The various Eiffel compilers will warn the user that a 'require else' form is needed -- but they don't require any corrective action be taken.
Let's say we have a parent class 'A', and a derived class 'B' that violates a precondition per Findler's paper. The user of broken class 'B' gets a confusing error message (or worse, perhaps just a failure of some kind) that does not indicate that the problem is with the improper class hierarchy.
|
|
Ehud Lamm - Re: Findler's Contract Flaw Analysis and Eiffel
12/17/2002; 10:46:59 AM (reads: 321, responses: 0)
|
|
|
I am not sure I understand your point. The issue is with the contract notation Eiffel imposes. The substitution errors are not compile time errors.
|
|
Brent Fulgham - Re: Findler's Contract Flaw Analysis and Eiffel
12/17/2002; 1:12:25 PM (reads: 293, responses: 1)
|
|
|
Findler's paper discusses a way of dynamically assigning blame for cases where the object behavioral hierarchy has been violated. This identifies the failure point, making it easier to find and correct defects.
I think this is an important point.
|
|
Ehud Lamm - Re: Findler's Contract Flaw Analysis and Eiffel
12/17/2002; 1:16:16 PM (reads: 307, responses: 0)
|
|
|
Sure.
|
|
|
|