--- Comment #12 from deadalnix <> 2012-05-03 01:43:42 PDT ---
(In reply to comment #11)
> >The current specification is flawed. It have nothing to do with how 
> >inheritance work (and I could assure you I know what I'm talking about, and 
> >I'm also pretty sure Timon knows also).
> Mistakes happen to the best of us. In this case the specification is correct
> and the bug report is in error. Derived classes may require less and provide
> more, which in contract lingo translates into weaker "in" contracts and
> stronger´┐Ż"out" contracts. This is not a matter in which reasonable people may
> disagree and not a matter of opinion.

I think you misunderstood what we are talking about here, as Walter is.

Nobody here discussed teh fact that in contract shouldn't become weaker when
inherited. This is, indeed, what corect OO design is.

What is discussed here is, with all details.

class A {
    void foo() in { ... } body { ... }

class B : A {
    override void foo() in { ... } body { ... }

then, let's consider :

fizbuzzA(A a) {; //'s in contract is valid

fizzbuzzB(B b) {; // ( OR's in contract is valid

The point is that's in contract loosen's in contract. And fizzbuzzA
have no knowledge of the fact that a subclass of A's instance can be passed.
So, if fizzbuzzA use foo with parameter that validate's in contract, but
not's in contract, it is an error. fizzbuzzA have no knowledge of the
runtime type of a, so shouldn't pass argument to foo that is invalid according
to's in contract. If it does, it means that fizzbuzzA is bugguy, or does
know about that fact that a isn't of type A, which is exactly what we DON'T
want when doing OOP.

It is Liskov substitution principle, any object of type B can be substituted to
an object of type A without the code using the object knowing about it. It is
probably the most important thing in OOP.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to