Tryton - Issues

 

Message32362

Author ced
Recipients jcavallo, nicoe, pokoli, reviewbot
Date 2017-03-08.15:45:05
Content
On 2017-03-08 15:01, Jean CAVALLO wrote:
> > 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 ?

It is bad to have different behaviour.

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

I do not understand "fine-tuning".

> 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 :
> 
> TaxLineMixinOverride
> account.invoice.line
> TaxLineMixin

I see no problem.

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

I do not understand. You do not have to override all methods. It is
object oriented programming.

> IMO, the
> "logical" Mixin extension should look like :
> 
> account.invoice.line
> TaxLineMixinOverride
> TaxLineMixin

I think we do not have the same logic.
And I do not see why one mro will be better than another except the one
that is consistent with the rest of the framework.
History
Date User Action Args
2017-03-08 15:45:06cedsetrecipients: + nicoe, pokoli, jcavallo, reviewbot
2017-03-08 15:45:06cedlinkissue4735 messages
2017-03-08 15:45:05cedcreate

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