Gregory Bond <[EMAIL PROTECTED]> writes:
> phil hunt wrote:
>> Let q(x) be a property provable about objects x of type T. Then
>> q(y) should be true for objects y of type S where S is a subtype of T
>> To me, this is nonsense. Under this definition any subtype must
>> behave the same as its parent type, becausde if it doesn't there
>> will be some q(y) that are different to q(x).
>
> Not necessarily..... the set of operations on y could be a superset of
> the set of operations on x. So you could have q(y) == q(x) (for all q
> applicable to x) but there could be w(y) that has no w(x). In C++
> terms, this implies no virtual functions.
No, it doesn't imply no virtual functions. It just restrains their
behavior severely. You do have to agree that you can't prove things
about code that raises exceptions, though. To deal with that in q(x),
you provide a domain for x over which q(x) doesn't raise exceptions.
You can then implement a subclass that overrides methods involved in
q(x), so long as they behave the same for all x. However, for some y
not in x, q(y) may now be a provable property rather than an
exception.
For instance, a class that has a method that takes the square root of
an argument could have properties that can only be proven for
non-complex values of that argument. A subclass could extend the
method to deal with complex values for that argument without violating
the LSP.
> Which is not to say that I'm disagreeing with your basic point:
> insisting on q(y) == q(x) for all q will greatly limit your use of
> polymorphism, unless you are 'sensible' (or perhaps what a
> mathematician would call 'loose') about how you define your "q"s!
Well, insisting that all existing program remain correct in the face
of introducing new types will greatly limit your use of
polymorphism. The LSP is more strict than that.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
