> 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

Attachment: pgp1H7z9PSBdI.pgp
Description: PGP signature

Reply via email to