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

Groups > comp.lang.python > #91158

Re: mix-in classes

Show key headers only | View raw

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.

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: mix-in classes random832@fastmail.us - 2015-05-23 23:27 -0400

csiph-web