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 _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
