>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.

Thanks, yes, the concept of a decorator is something I first saw in the last 90's. I wouldn't remember exactly were it was but I would guess Phoenix. lol

Thanks for the info