[Raymond] >> Cooperative multiple inheritance is *not* about mixing two unrelated >> parents that just happen to use the same method name but have >> different semantics and were not designed to cooperate with each other. >> >> The A-B-C-D diagrams and foo/bar methods in the examples are >> deceptive because they silently drop the precondition of cooperation >> while attempting to demonstrate a supposed flaw in the tool. [Michele] > They just show that the tool is delicate and not easy to use. To me, they miss the point. Simply, if you don't have diamonds, then super() is easy to use and if you do have have diamonds, then super() is the *only* way to do it. Diamonds impose a set of design constraints (making the classes cooperative). The A-B-C-D diagrams ignore this point and make super() seem like an accident waiting to happen. In contrast, with a concrete example, accidental non-cooperativeness would be more self-evident. The problem isn't that super() is fragile. The problem is that a cooperative design pattern requires you to actually make the classes cooperate. This is no different than a visitor design pattern requiring that you attach a conformant visit() method for on each of the visited classes. [Michele] > In my experience, one can go a long way using composition instead of > inheritance. While that is often true, I don't think it applies to the case of cooperative multiple inheritence. To achieve substantially the same functionality using composition, you would likely have to re-invent much of what super() does for us automatically, and you would still be imposing constraits on the composed classes that are substantially the same as what you have with inheritance. [Michele] > I also think that Python would not lose much without cooperative > multiple inheritance. I would state this differently: "The use cases for cooperative multiple inheritence don't arise often in practice; so, if we dropped support for those cases, you probably wouldn't notice until you encountered one of the rare occasions where it was the right answer to your problem." There was some quote floating around that expressed the situation well -- it went something like: "Python makes most problems easy and hard problems possible". The use cases for cooperative multiple inheritance fall in the latter category. BTW, I really like your paper explaining the MRO. Excellent work. Raymond
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