openerp-expert-framework team mailing list archive

[Xavier Morel <xmo@xxxxxxxxxxx>]

On 2012-04-25, at 15:32 , Lionel Sausin, de la part de l'équipe informatique Numérigraphe wrote:

> Dear Vo Minh Thu,
> 
> Sorry if this topic has been raised already, but I couldn't find details on how inheritance will be coded in the new API.
> If possible, I humbly suggest we chose another syntax than "_inherit" and "_inherits".
> They have been disturbing to new developpers all the time: they can't rely on what they know about "inheritance" from their OO programming background

Depends what their OO programming background they have, Ruby users know about open classes already.

> or their python skills :
> - they think they can use inheritance to express generic/specific relationships (X' is a X)

They can, although the way the ORM works means this is mostly useless.

> - they expect to be able to use the parent class independently of it's children

This is also perfectly possible (and done).

> "_inherit" actually changes the behavior of the existing class, so a decorator like "@overlay", "@redefine" or "@extend" would be more explicit.

That is not quite correct: _inherit re-opens the class if alone, and creates a sub-class when paired with _name.

> Or we could rely on plain python inheritance, but they're not really expressing the same concepts are they?

There are ways to implement open classes in Python, but it's going to be just as weird (in slightly different manners).

> "_inherits" is more like a composition relationship (a product variant is made of a template) so maybe a decorator "@component" would be more adequate.

_inherits is a pretty direct mapping to Postgres's table inheritance[0]. It's not quite composition either.

[0] http://www.postgresql.org/docs/8.1/static/ddl-inherit.html