On Saturday 24 August 2002 08:44 am, Guido van Rossum wrote: ...
For example, if we ever are going to add argument type declarations to Python, it will probably look like this:
def foo(a: classA, b: classB): ...body...
It would be convenient if this could be *defined* as
assert isinstance(a, classA) and isinstance(b, classB)
I was hoping this could be defined as: a = adapt(a, classA) b = adapt(b, classB) but I fully agree that, if we have an elegant way to say "I'm inheriting JUST for implementation, don't let that be generally known" (C++'s private inheritance is not a perfect mechanism, because in C++ 'private' affects _accessibility_, not _visibility_, sigh), it can indeed be handier and more productive to have interfaces and classes merge into each other rather than be completely separate. Substantial experience with C++ (merged) and Java (separate) suggests that to me. From the point of view of the hypothetical 'adapt', that suggests the 'protocol' argument should be allowed to be a type (class), rather than an 'interface' that is a different entity than a type, and also the useful implication: isinstance(i, T) ==> adapt(i, T) is i
so that programs that have a simple class hierarchy can use their classes directly as argument types, without having to go through the trouble of declaring a parallel set of interfaces.
The "parallel set of interfaces" (which I had to do in Java) *was* indeed somewhat of a bother. Any time you need to develop and maintain two separate but strongly parallel trees (here, one of interfaces, and a separate parallel one of typical/suggested partial or total implementations to be used e.g. in inner classes that supply those interfaces), you're in for a spot of trouble. I even did some of that with a hand-kludged "code generator" which read a single description file and generated both the interface AND the class from it (but then of course I ended up editing the generated code and back in trouble again when maintenance was needed -- seems to happen regularly to me with code generators). Surely making the target language directly able to digest a unified description would be nicer.
I also think that it should be possible to come up with a set of standard "abstract" classes representing concepts like number, sequence, etc., in which the standard built-in types are nicely embedded.
If you manage to pull that off, it will be a WONDERFUL trick indeed. Alex