> > > A few weeks ago I realized there was reason in principle that > > ^^^^^^^^^^ > > Did you mean "was no reason"??? So did you? > > > declaring a class satisfies an interface shouldn't just amount to > > > adding the interface to the class' __bases__ (as Guido has been > > > suggesting all along). > > > > > > Why not? Am we missing somethings? > > > > We'd need a trick to deny an interface that would be inherited by > > default. Something like private inheritance. > > I think it's more than that. You might need to "uninherit": Say > Interface A begets class B which begets class C. What if C doesn't > fulfill A? Sorry, I meant to include that case. How do you do that in C++? Inherit privately from B and publicly from A, and making A virtual base everywhere? > > There's also the ambiguity of inheriting from a single interface: does > > that create a sub-interface or an implementation of the interface? > > Of course with your C++ hat on you probably don't care. On Mondays, > > Wednesdays, Fridays and alternating Sundays I don't care either. > > With my C++ hat on I can't even imagine this. In C++ we don't > express interfaces in code: they're written down as "concepts" in > the some documentation somewhere (no, I don't think an abstract > class in C++ is a good analogy for these Python interfaces). What's the difference between an abstract class and an interface in C++? --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4