"Michele Simionato" <[EMAIL PROTECTED]> writes:
I think you're replying to me, but you didn't include any indication
so I can't be sure.
> If I understand correcly you have a situation like this:
>
> Base
>
> |
>
> Parent1 Mixin
> | |
> | |
> Children1
>
> Base
>
> |
>
> Parent2 Mixin
> | |
> | |
> Children2
>
>
> Base
>
> |
>
> Parent3
> |
> |
> Children3
Mostly right. What missing from the diagram is that there are three
Base classes: Base1, Base2 and Base3. They have no methods in
common.
> The Base class is pretty general, Parent1, Parent2 and Parent3 are more
> specific, Children1 and Children2 requires the Mixin class, but
> Children3 does
> not require it.
At least one ParentX also uses Mixin.
> Let me note that this looks like a sensible design and that I agree
> that in simple
> situations multiple inheritance could be the simplest solution.
Thank you.
> Nevertheless 1) I am scared of the case where you have hundreds of
> methods coming from everywhere (ex. Zope) and
Any tool can be abused.
> Various solutions (using pseudocode):
> 1. use single inheritance and attach the mixin methods by hand:
> 2. use single inheritance and delegation. If "mixin" is a proxy to
> the methods in the mixin (for instance implemented as an attribute
> descriptor) you could do
These two are cases of what I was talking about when I referred to the
Church-Turing thesis. Also, I don't see how they make the situation
you are scared of above any better.
> 3. think differently and use multimethods
>
> There are implementations of multimethods in Python (for instance in
> PEAK).
> This example looks like a good candidate for a multiple dispatch
> solution.
> You would use single inheritance and promote the mixin methods to
> multimethods.
I don't see how that would help at all. You haven't done anything
about solving the base problem - that getting the methods into my
classes cleanly needs multiple inheritance. Further, I don't need
methods that are distinguished based on their arguments - they all
take a fixed set of arguments, and operate on them and the state of
the instance. None seem to be candidates for being multimethods. The
mixin methods tend to provide general functionality, and get used in
radically different places by the different child classes.
You did miss the one alternative I considered: making the methods of
Mixin stand-alone functions, and passing them extra arguments instead
of using attributes of the instance. They would all then look like
mixin_func(self.foo, self.bar, var, value). I decided that this wasn't
as readable as inherting the methods.
> BTW, I think multimethods are pretty nifty and I would welcome them
> in standard Python.
I wouldn't bet on it happening. They seem to violate "explicit is
better than implicit".
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
