Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #91163
| References | <CADL-DviUKRgpk-hmK6kqYik0D6bWLXveRLjNWqZPAbximmHhSQ@mail.gmail.com> |
|---|---|
| From | Ian Kelly <ian.g.kelly@gmail.com> |
| Date | 2015-05-24 01:39 -0600 |
| Subject | Re: mix-in classes |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.8.1432453224.5151.python-list@python.org> (permalink) |
On Sat, May 23, 2015 at 7:53 PM, Dr. John Q. Hacker <zondervanz@gmail.com> wrote: > The post on "different types of inheritence..." brought up a thought. > > Let's say, I'm adding flexibility to a module by letting users change class > behaviors by adding different mix-in classes. > > What should happen when there's a name collision on method names between > mix-ins? Since they're mix-ins, it's not presumed that there is any parent > class to decide. The proper thing would seem to call each method in the > order that they are written within the parent class definition. > > I suppose one can create a method in the parent class, that runs the mixin > methods in the same order as in the inheritance list, but would there be a > better way for Python to enforce such a practice so as not to create class > anarchy? (A problem for another topic.) Usually with mixins, one just wants to call a method of a specific mixin; a name collision is likely a symptom of poor design, and it would be unusual to want to call *all* mixin methods with the same name. If you really want to do that for a particular method though, is there some reason why super() won't suffice?
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: mix-in classes Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-24 01:39 -0600
csiph-web