[Python-Dev] Re: Int FutureWarnings and other 2.4 TODOs

[Mike Thompson]

"Guido van Rossum" <guido at python.org> wrote in message
news:200312031610.hB3GA1204029 at 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