Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #91155 > unrolled thread

mix-in classes

Back to article view | Back to comp.lang.python

Contents

  mix-in classes "Dr. John Q. Hacker" <zondervanz@gmail.com> - 2015-05-23 20:53 -0500
    Re: mix-in classes Steven D'Aprano <steve@pearwood.info> - 2015-05-24 21:11 +1000
      Re: mix-in classes Michael Torrie <torriem@gmail.com> - 2015-06-16 22:39 -0600

#91155 — mix-in classes

[Multipart message — attachments visible in raw view] — view raw

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.)

zipher

[toc] | [next] | [standalone]

#91168

On Sun, 24 May 2015 11:53 am, Dr. John Q. Hacker 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.

That's one possibility. Another is to have precedence rules, e.g. "first
mixin wins". If a mixin wishes to support additional mixins with the same
method, in a cooperative fashion, they can call super().

But, frankly, what you describe is more likely to be a weakness of multiple
inheritance and mixins, one which should be avoided. One attempt to avoid
this problem is with traits, an alternative to mixins which explicitly
deals with the problem of mixin conflicts.

http://www.artima.com/weblogs/viewpost.jsp?thread=246488

(Unfortunately, the language used to describe mixins, traits, multiple
inheritance and related concepts is not always consistent. Ruby mixins
don't use inheritance; Scala traits are more like Python mixins than Squeak
traits; and Python mixins are, of course, merely a convention layered over
multiple inheritance.)

> 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.)

Try strait:

https://pypi.python.org/pypi/strait


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#92723

On 06/16/2015 07:55 PM, Dr. John Q. Hacker wrote:
> Interesting.  This brings up an issue another poster brought up:  In my
> usage of the term "parent", I use it to mean the class that is a product of
> object composition:
> 
> class Parent(child1, child2):  pass

Hmm. This is a definition of "parent" I've never heard of before.  And
it's opposite to the use of the word in all contexts I'm aware of.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web