Tryton - Issues



Author jcavallo
Recipients ced, nicoe, pokoli, reviewbot
Date 2017-03-08.15:01:52
> I do not see the point. This makes Tryton "Mixin" inheritance
> working differently than the usual inheritance.

I am not sure to understand what you mean, could you elaborate ?

> Also modifying the __bases__ attribute is quite questioning
> (not sure it is allowed in every implementation).

Agreed, it may need some investigation. But we could achieve the
same result by registering in two passes (add a register_meta
method on modules to "build" the base classes, then calling the
regular register).

> Finally, I think it is good practice that Mixin should not depend
> on the place it has in the mro like that it prevents some
> side-effects.

It simplifies the implementation of the current feature, but I
think it will make "fine-tuning" of Mixin classes a little
complicated. For instance, I think you said you wanted to be able
to override existing Mixin classes (do not remember exactly when,
so correct me if I'm wrong). But doing so will be difficult with
the current implementation.

For instance, if one wants to override the TaxLineMixin class,
the mro will be something like :


So the implementation of the TaxLineMixinOverride will have to
deal with all method overrides that may have taken place in
the models that extended the base TaxLineMixin class. IMO, the
"logical" Mixin extension should look like :

Date User Action Args
2017-03-08 15:01:53jcavallosetmessageid: <>
2017-03-08 15:01:53jcavallosetrecipients: + ced, nicoe, pokoli, reviewbot
2017-03-08 15:01:53jcavallolinkissue4735 messages
2017-03-08 15:01:52jcavallocreate

Showing 10 items. Show all history (warning: this could be VERY long)