April 3, 2022
2:35 p.m.
Chris Angelo writes : > You start out with the assumption that MOST PEOPLE think of super as a > way to call THE, singular, parent. If this is indeed a problem, then > it's not a problem with super, it's a problem with expectations. This is not so much a problem as this is the context we're working under. If we're defining / updating features of the langage, people understanding of the langage do matter. A feature that would stick closer to the expectation of most people would provide a much smoother learning curve, for most people. And just to make it clear, I am not under the impression super can only target one class. What i'm saying here is that it is the most common impression the average developper would have. > I got a little bit further into your post and found you fighting hard > against the existing feature, and that's when I gave up on reading it. ugh. Let's make it simple then. Do you agree this list to be a comprehensive list of use case / feature of today's MRO + super: 1) method resolution 2) parent proxying 3) dependency injection 4) sideway specialisation (Mixins use case) Not really a use case / feature, but related: 5) the diamond problem If you have any doubts about what i mean by any of those, i describe them at the top of my lengthy post. > You've already been given a solution to your problem: if you don't > want super, don't use super. And lose dependency injection and sideway specialisation. (And obviously the proxying feature) Which is the most common complaint against my proposal : the loss of those use cases. And my proposal now accounts for those cases, unlike this solution. > At the very least, test all your code blocks and > fix the typos in those. I do test my code blocks, but if you find errors, please let me know. About typos, english is not my native langage, so i'm most likely blind to some of them, as much as i wanna apologise, it's not really in my control, again, let me know if some of them hurt your eyes.