From: Jason H. <ja...@pe...> - 2003-04-12 19:30:54
Attachments:
mixin.patch
|
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 ja...@pe... |