[Python-3000] Abilities / Interfaces
Guido van Rossum
guido at python.org
Thu Nov 23 00:38:19 CET 2006
I'm concerned about the additional wrinkle where there is a library
that calls the factory to produce A's and then turns around and passes
them on to *another* library. Now the other can deal with A's but has
recently been upgraded so that it works much better with B's; but it
doesn't know that A's are fine B's already. ideally, there'd be an
indirection in there somewhere that would let us insert a conversion
from A to B; but if there isn't, it would be nice to be able to poke
into A a marker indicating that it also supports B.
Somehow that looks nicer with interfaces than with ABCs.
On 11/22/06, Bill Janssen <janssen at parc.com> wrote:
> > On 11/22/06, Bill Janssen <janssen at parc.com> wrote:
> > > Something like
> > >
> > > class MyNewClass (ExistingClass, OtherInterfaceIJustNoticedExistingClassImplements):
> > > pass
> > No, unless you can also patch up all code that creates ExistingClass
> > instances. You alluded to this before and it sounded like you didn't
> > think it was an issue. Why do you think that? I see it as a huge
> > problem when retrofitting pre-existing third-party code.
> I don't think the specific issue raised above is very important (wow,
> I just noticed that type A also implements the equivalent of interface
> B, so I wish I could treat A as a B, but darn it, I can't since it
> didn't inherit from B). I think that ad-hoc adapter classes work OK
> for handling that rare and incidental case, in the extremely rare case
> that it *has* to be handled.
> Not to say that there aren't interesting problems, though I'm not sure
> just how "big" they are. The biggest issue I see is the factory
> problem. The other is the existing value problem, which is a variant
> on either the above or the factory problem.
> Factory problem: This is a known OO problem. You're given a factory,
> which produces instances of type A. You've got B, which is a subtype
> of A, and you wish the factory would return that, since nobody who
> knows anything uses A instead of B anymore. You've got a number of
> options: (1) change the factory to produce B instead of A; (2) wrap
> each instance of A in a B which forwards A's methods to the original
> instance; (3) somehow change the instance of A into an instance of B.
> (1) is often practically not possible, though it's probably the right
> thing to do. In fact, "factories" should always be built to be
> extensible (that is, they should be built so that user code can
> register a new factory if desired). (2) is always possible, but takes
> some extra coding. It would be nifty if Python could have a standard
> way of doing (3). That's what I'd aim for. That would solve all
> three of these related problems. Notice, however, that (2) and (3)
> would probably look pretty much the same for the practicing
> myB = coerce_to_B(factory.produce_A());
> (3) is practically speaking only possible for types which have
> relatively independent initializers.
> Is munging __bases__ so terrible? Isn't it just:
> def ensure_base (i, clss):
> if not isinstance(i, clss):
> class X (i.__class__, clss):
> i.__class__ = X
> return i
> Would be nice to have anonymous classes :-).
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000