On 6/04/22 5:52 am, malmiteria wrote:
Some exemple i give including, but not limited to the gobelin exemple are a fair use case in which you'd want to use the argumented version of super.
No, the gobelin example is an example of when NOT to use super(). Multiple people have told you that, but you don't seem to be listening.
The exemple i always give : you have multiple view class, you have the permission mixin, so you (as a lib author) wanna provide all possible combinations of simple view class, and permission mixin augmented view class. today's only (reasonable) way is ML.
I would need convincing that this isn't better done by composition than MI. Give the View class a Permissions attribute that determines what it's allowed to do.
Essentially, (i'm talking about what i understand you consider a properly designed ML scenario): ``` class A(P1,P2): ... ``` Is 100% equivalent of ``` class A(P2,P1): ... ``` correct me if i'm wrong.
No, what I'm saying is that if you have class A: ... class B: ... class C(A, B): ... class D(E, F): ... class E(C, D): ... you shouldn't have to worry about how A, B, E and F get interleaved in the MRO of E. You can rely on A being before B and E being before F, but E could come either before or after B, etc.
Also, i do wanna mention that you do in fact care, to some extent to which order things are called in. Not always, but in some cases you do, and not being able to target one of the parent first, instead of the default one, when the default one is not appropriate is a problem.
Well, I disagree. I still maintain that if you need to target a particular base class, super() is the wrong thing to use and will only lead to difficulties if you try to use it that way. I actually think super() is misnamed and should really be called next_class() or something like that. There might be less confusion about its intended use then. -- Greg