I've been in MiddleKit.Design, adding support for PostgreSQL and
Samples.csv, when I got sidetracked with a mix-in issue.
According to a few of Chuck's comments sprinkled throughout the source,
"invoking super is the only awkward aspect of mix-ins that hasn't been
solved". But invoking super is what I needed to do. So I started
looking more closely at MiscUtils.MixIn, and started making changes
(patch attached).
I added a parameter called mixInSuperMethods (defaults to false), which,
when true, binds the original methods in the class to specially-derived
names in the mix-in class (the naming scheme is 'mixInSuper' +
OriginalMethodName).
Doing this means that the superclass methods are only available from
that mix-in class, but I think this makes sense, since that's the only
place you'd ever want them. I grappled with the problem for a while
before making this realization, after which the solution seemed obvious.
The semantics for multiple mixins are what you'd expect, but the order
of the calls depends on the order in which the classes were originally
mixed. Here's an example:
from MiscUtils.MixIn import MixIn
class Foo:
def bar(self):
return 'Foo'
class FooMixIn:
def bar(self):
value = FooMixIn.mixInSuperBar(self)
return value + ", FooMixIn"
class FooMixIn2:
def bar(self):
value = FooMixIn2.mixInSuperBar(self)
return value + ", FooMixIn2"
MixIn(Foo, FooMixIn, mixInSuperMethods=1)
MixIn(Foo, FooMixIn2, mixInSuperMethods=1)
f = Foo()
print f.bar() # prints 'Foo, FooMixIn, FooMixIn2'
I think being able to invoke super from mix-ins will allow us to avoid
some awkwardness in the code, and use mix-ins a bit more naturally, so
I'm interested in committing this change, and starting to make use of it
in MiddleKit. Comments? Suggestions for a better naming scheme? Does
anyone (hi, Chuck!) see any potential pitfalls?
--
Jason D. Hildebrand
jason@...
|