> If "changing that functionality beyond recognition" means changing its > external behavior (as opposed to its internal behavior) so that it > acts differently from what the superclass had promised to do, then > no, it's not any weirder--but I can't figure out how the contract > would work, either.
That's because you're used to one way of thinking about class inheritance: that the subclass can do everything that the superclass can do, and more. In this scheme, you might have a Square class, with a field representing its corner and another giving its side length. Then, you could build on this to have Rectangle as a subclass, which adds an extra side length, and extra accessors for it. This is a really bad way of making your subclasses work, but your Rectangle has all the fields and methods of your Square, and some extra ones. Another way of looking at it is that the Rectangle is the more generalised one, so it should be the superclass. It has a corner and two side lengths, and associated accessors. Now, your Square is a subclass of this. A Square in this scheme isa Rectangle, with the constraint that the two side lengths are always equal. (Never mind the storage considerations: that's internal.) In the first scheme, even though the subclass only adds capabilities, it breaks the isa relation, because a (real-world) rectangle is not necessarily a square. If you write code that takes a Square, and you give it a Rectangle, all the function calls will still work, but the functionality will be wrong, because it makes assumptions that are no longer true. In the second scheme, the isa relation holds on the real-world things you're abstracting, because a (real-world) square isa rectangle. But the assumption you want to make, that you can call any superclass method on the subclass, no longer really works. (As people said, you can hack around it, but fundamentally it's wrong.) So, if you write code that wants a Rectangle, and you give it a Square, you have to pussy-foot around this externally imposed constraint, but the (smaller set of) assumptions still hold. Most languages use the first scheme of class inheritance, but some offer the second. Perl 6, AFAICS, has the first for subclasses, but offers the second with subtypes and where clauses. I don't believe I've previously used a language that offered both, so I'm interested to see how this conjunction of features will turn out. -- "For God's sake, please give it up. Fear it no less than the sensual passion, because it, too, may take up all your time and deprive you of your health, peace of mind and happiness in life." Wolfgang Bolyai, urging his son to give up his research on non-Euclidean geometry
pgp1H7z9PSBdI.pgp
Description: PGP signature
