to dive into conceptual ideas a bit more: inheritance is usually what we do when we mean *is a* for exemple, a cat *is an* animal, so we would write it like that: ``` class Animal: pass class Cat(Animal): pass ```
I believe my gobelin exemple is a fair case of MI since we can definitely say halfbreed *is a* corruptedgobelin *and a* proudgobelin. In such a case with multiple *is a* there's multiple strategies to blend in the multiple *is a*. One strat is chaining the *is a* : a cat *is an* animal, and an animal *is a* living being. We simply chain simple inheritance. Another strat is to say that some attributes / behaviors of one parent override the over, like dominant genes. Today's MRO implicitely overrides all method from the second parent with method from the first parent. Essentially, the first parent (in declaration order) is dominant on all attributes. This isn't very subtle, as we could want some attribute of each parent to be dominant, while others to be recessive. My "can't assume one parent is more specialised" (can be found here : https://github.com/malmiteria/super-alternative-to-super/blob/master/conversation/README.md#cant-assume-on-parents-more-specialised) showcases such a scenario. The diamond problem essentially raises the question, if you are a 1 and a 2, and 1 and 2 are numbers, are you a number twice, or once? If by 1 and 2 you mean 3, you're a number once. If by 1 and 2 you mean (1, 2) you're a number twice. Today, it defaults to once in all cases. This can cause unexpected behaviors, such as showcased by the gobelin exemple (can be found here : https://github.com/malmiteria/super-alternative-to-super/blob/master/conversation/README.md#diamond-tree-repeat-top) I believe the mixin case to be a little bit different. I think a mixin is a *but with* kind of relationship. for exemple: a sphynx is a cat, *but without* hair you can find my exemple here : https://github.com/malmiteria/super-alternative-to-super/blob/master/conversation/README.md#way-too-big-combinatory-possibilities i think it is fair to say that those scenarios are well served by simple inheritance, but can't in practice define the "but with" class as the child of any other, since the "but with" (aka mixins) could be applied to multiple parent class. That's why my proposal for those cases is to allow inheritance to be postponed after definition time, and set by the final child class that inherits from those. ``` class Sphynx(Hairless(Cat)): pass ``` Instead of ``` class Sphynx(Hairless, Cat): pass ``` Now, there's another thing in the language that today seems like a "but with" to me, and it's decorators. ``` @http_errors_handling def answer_api_calls(request): pass ``` means answer api calls, but with http errors handling. So i guess using the @ syntax could be meaningful too: ``` class Sphynx(Cat @ Hairless): pass ``` where Cat @ Hairless would produce a resulting class being a copy of Hairless, with Cat as a parent. This makes it easy to chain lots of mixins without having to add tons of parenthesis, so it might be a better syntax that the one i originally proposed. Also, some of you mentionned composition is an option for some exemples i gave. I believe composition to be more a *has a* kind of relationship. This is something i believe to be "common intuition", that's how most people are taught what OOP is. Wether it is or not, it matters to make sure that the different concepts we use always mean the same thing in all their use cases. This makes for a very smooth learning curve, compared to concepts that mutate over context. And overall, having to switch from a *is a* relationship to a *has a* relationship, simply because the langage doesn't allow *is a* in some cases hints at excessive limitations of the langage. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FFOQHTR47WF7GQYDWBU6SKEBW57IVLZS/ Code of Conduct: http://python.org/psf/codeofconduct/
