Re: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

["Eirik Mangseth" <eirik@otp.no>]

"Matthew J Heaney" <mheaney@on2.com> wrote in message
news:7r66qbf1xw.fsf@butter.albany.duck.com...
> Greg <gmc333NOgmSPAM@my-deja.com.invalid> writes:
>
> > In Eiffel, DbC works with inheritance. So a subclass is bound to the
> > same contract as its parent class automatically. Not being an Ada
> > guru, I'd guess you would have to copy the parent's contract into the
> > child, leading to undesirable duplication.
>
> Yes, it's true that Eiffel's contract-checking is more sophisticated
> than a simple assertion-check.  However, Eiffel *has* to be this way,
> because the idiom in that language is inheritance-based programming.
> Abstractions are composed using inheritance.

Oh god, not again. This is not true at all. In OOSC2 the author asks the
question: "Would you rather buy or inherit" and goes to great length
in discussing the pro and cons of both approaches. As every experienced
Eiffel (and OO programmer knows) inheritance and aggregation are
complementary and their usage depends on the goals you try to achieve.

Instead of stating such claims, why don't you sit down and learn the
language?

>
> But in Ada, it's very rare that you have deep inheritance lattices,
> because there are language features that allow you to compose
> abstractions using aggregation.

In Eiffel as well.

> So contract checks don't need to be any
> more sophisticated than simple assertion checks.
>
>

And all programming can be done in assembly


best regards

Eirik Mangseth
Stockpoint Nordic AS
Lysaker, Norway

"If I can't Eiffel in heaven, I won't go"