"Guido van Rossum" <guido@python.org> wrote in message news:200312031610.hB3GA1204029@c-24-5-183-134.client.comcast.net...
It's not me, it's Barbara Liskov at MIT.
:-)
(For non-OO wizards, this is called "Liskov substitutability".)
The general notion is that if Y is derived from X, then you should be able to use a Y wherever you might otherwise want to use an X. In other words, Y should support every operation that X supports, but Y can add operations of its own.
So the question is, does long have operations that int doesn't have? And if so, why can't those operations be added to int? And if there's a reason, is it good enough?
If the sets of operations are identical, is there a way to break the tie?
In this case, one could argue that no tie breaker is needed. If one accepts that int and long have the same operations but offer different implementations, then the obvious solution is: an abstract base class (Int) and two sub-classes (Short and Long?). Of course, this obvious solution has a problem: a programmer can't easily sub-class Int. They must choose one a sub-class from Short or Long (unless they want to provide a full implementation themselves) and that's probably not a decision they want to make. Perhaps, because of this, the GOF "Bridge Pattern" might be suitable here. (This pattern can be framed as: "adapt multiple implementations to an interface using delegation" -- which, after all, is pretty much what the vtable in previous solution gives you.) If the existence of Short and Long is an implementation detail best hidden from the python programmer, then a Bridge Pattern implementation has a lot going for it. Use of the Bridge pattern might even allow for three different implementations: PreDefined, Short, Long ... where PreDefined is one of the numbers between 0 and 256 which I'm given to understand are pre-allocated by the runtime environment. -- Mike