>>Are you refering to Mixin-Classes ?
>
>...as in inheriting from several super classes, which I referred as base classes

You have already received a lot of correct answers.
My personal definition of MI is implementation inheritance from more than one base class.
Mixin Classes are a special case where some functionality class (the "mix-in"),
- for arguements sake the ability to persist the current state in a JSON or XML string -
can be added to more than one other class (for instance all WPF, WinForm and WebForm controls)
by creating new classes based on the xxxForm.Control and the Mixin class.

vfp-like (clearly impossible due to vfp SI implementation) pattern would be

Define Class PerChekcbox as Checkbox, persistMixIn
    func Persist2String()
       wait wind "works in Checkbox"
       return dodefault() 
enddefine

Define Class perButton as Button, persistMixIn
    func Persist2String()
       wait wind "works in Button"
       return dodefault()
enddefine

Define Class persistMixin as Custom
    func Persist2String()
       ....
EndDefine

Can be thought of as a decorator pattern and in Java/C#/Vfp IMHO the more maintainable implementations
work via aggregation/composition, not interface inheritance, albeit at a minuscle perf hit compared to II.

In Python (and that includes the Dotnet-Ironpython!) you would have even less code using
the above described Mixin-Pattern. When looked at it from such an angle, the risk of code in a click-method
is less threatening, as the Mixin usually has clearly formulated areas of interest. Naming conventions
can help in very large projects, but in my (limited!) exposure to python-style MI the fear generated in
SI circles like Java and C# was out of proportion to the actual risc.

YMMV

thomas