On Fri, Apr 22, 2022 at 08:46:38PM +1100, Matsuoka Takuo wrote:
On Fri, 22 Apr 2022 at 15:47, Christopher Barker <pythonchb@gmail.com> wrote:
Sure -- but there's nothing special or difficult here -- refactoring can create breaking changes. I believe it was part of Hettinger's thesis in "Super Considered Super" that the use of super() is part of the API of a class hierarchy. Indeed, the MRO of a class hierarchy is part of the API. If you change the MRO, it is a potentially breaking change, just as if a method is added or removed, or renamed, or ...
So I may not have been told a refactoring like that shouldn't involve a new instance of overriding, but may I have essentially been told I shouldn't refactor at all if I didn't want to create breaking changes?
Pretty much. In general, any change to the MRO is a potential breaking change, unless you design your classes very carefully. See for example this Django ticket: https://code.djangoproject.com/ticket/29735?cversion=0&cnum_hist=3 **Inheritance is hard.** The easy cases are so amazingly easy that people are shocked when they run into complicated inheritance designs and discover how hard they are. Some people respond by refusing to believe that inheritance is hard, and insisting that there has to be a Magic Bullet that will make everything Just Work, or they blame super(). But the problems aren't with super(). Other people respond by saying that inheritance is just a tool, and if the tool doesn't work you should use a different tool which is better suited to what you are trying to do. That tool might be to restrict the way you use inheritance to a smaller subset, or to use delegation, etc. -- Steve