[Types-sig] A challenge

[Martijn Faassen]

Christian Tismer wrote:
> 
> Tim Peters wrote:
> > [stuff on name equivalence]
> That sounds very right, since it allows to create different
> things even if they look the same from structure. You get more
> strength in error checking, since using the parameter in the wrong
> context can be detected even if a foo's components look like a bar's.

Okay, but then I'll repeat the question I asked before:

class Foo:
    def getIt(self)->String:
        ...

class Bar:
    def getIt(self)->String:
        ...
list = [Foo(), Bar()]

for el in list:
    print el.doIt()

This wouldn't work, even though the interfaces are similar. This brings
us into two domains:

* inheritance

I haven't seen too much discussion on how types are going to interact
with the inheritance system. I could of course let Foo and Bar derive
from a common base class which defines doIt() as well. This is a common
way to do it, if type annotations get inherited from base classes, etc.

* interfaces

Another way to do it is to use interfaces and say Foo and Bar both
conform to some interface which supports doIt(). This was something we
wouldn't discuss in this SIG, but can we in fact avoid it? 

Regards,

Martijn