Re: mix-in classes
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: mix-in classes
On Sun, May 24, 2015 at 6:11 AM, Steven D'Aprano wrote: > On Sun, 24 May 2015 11:53 am, Dr. John Q. Hacker wrote: > 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 > 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 I figure that it is this "Parent" class which must manage the methods that it is inheriting with child1 and child2 -- mixins or otherwise. In this usage, super() should be called "delegate" as whatever I don't accomplish in my specialized Parent class, I will get the child classes to do. Python automagically delegates any methods that I don't define in Parent to methods found in child1 and child2. It seems the issues that everyone encounters with multiple inheritance, mixins, and such has more to do with terminology (and proper implementation) than in actuality. zipher -- https://mail.python.org/mailman/listinfo/python-list
Re: mix-in classes
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: mix-in classes
On Sat, May 23, 2015 at 7:53 PM, 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. > > 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? -- https://mail.python.org/mailman/listinfo/python-list
Re: mix-in classes
On Sat, May 23, 2015, at 21:53, Dr. John Q. Hacker wrote: > 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. The way C#/.NET does its nearest equivalent to this is to have this be determined by what "mix-in" is in scope at the call site. That is, for example, the mix-ins for IEnumerable defined in System.Linq.Enumerable is only called if the System.Linq namespace has been imported. IIRC, it's an error for there to be two with identical signatures, which isn't an issue since you can simply explicitly call the method as Enumerable.Whatever(foo) instead of foo.Whatever(). One could imagine a similar mechanism for python... object.__getattr__ could, if nothing is found in the dictionary or by an overridden __getattr__ method, find the call site (construct a stack trace), iterate through an __mixins__ list in the calling module, search each mixin, in order (since it's a list, let's take advantage of it having an order since we haven't got the static type system to do a lot of sophisticated overload resolution), for a matching name. Ideally we'd also have a mechanism for mixin methods to be able to raise NotImplemented (or TypeError?) and have it continue down the list, but any mechanism I can think of for this has the disadvantage that if any of the mixins contains a matching callable it has to return a proxy rather than immediately raising an error, even if none of them actually works. -- https://mail.python.org/mailman/listinfo/python-list
