Re: [Modeling-users] specifying objects' class
Status: Abandoned
Brought to you by:
sbigaret
From: Sebastien B. <sbi...@us...> - 2004-02-10 22:07:26
|
John Lenton <jo...@vi...> wrote: > On Tue, Feb 10, 2004 at 04:57:02PM -0300, John Lenton wrote: > >=20 > > hmm... it isn't clear to me that this is always what you want; > > currently we're using (in an unrelated field) a linearization of that > > graph into > >=20 > > Employee <| Person <| EmployeeBase <| PersonBase > >=20 > > although I can see that in this case you are (on first sight at least) > > correct. However, no matter what is expected, it is exactly what the > > C3 MRO in python 2.3 does. If you want your behaviour, all you have to > > do is declare Employee as > >=20 > > class Employee(EmployeeBase, Person) > >=20 > > whereas if you want the other behaviour you declare it as > >=20 > > class Employee(Person, EmployeeBase) >=20 > after discussing it with Federico (Heinz) I realized I wasn't being > particularly clear on this point, so, at risk of boring you all to > death over a subject you care little about, I'll expand on this a bit. >=20 > First, Federico understood that S=E9bastien is suggesting that the > EmployeeBase class must explicitely inherit from Person, which is > seems odd to me; could you (S=E9bastien) clarify that? What I understood > you to mean was that the EmployeeBase MRO was as you described. As one > would never instanciate *Base objects, all is well. I only meant to say that the single-inheritance "approach": Emp -> EmpBase -> Person -> PersonBase is the one that is used when you generate python code with the mdl script, so in a way Federico understood me right ;) but I think I was not clear myself in what I wrote. The fact is that while py2.3 behaves as "expected", py2.2 does not. You can refer e.g. to http://www.python.org/2.3/mro.html, section Bad Method Resolution Orders. In fact, I did not want to << damage my brain >> to make sure that the scripts behaves as expected for py2.1, 2.2 and 2.3, so I just made it simple. Hence, the single-inheritance approach. Then, to make it clear :) - noone will probably ever want to instanciate *Base objects, right, - so this is equivalent to stating that the Employee MRO is: EmployeeBase, Person, PersonBase - the generated code is less flexible than using py2.3 multiple-inheritance, but it ensures that the MRO is the same for py2.1, 2.2 and 2.3 no matter how deep the inheritance hierarchy can be (the deeper it is, the worse the brain damage can be when thinking of MRO for all thos pythons :) > and now for something completely the same: >=20 > class PersonBase(object): > pass > class EmployeeBase(PersonBase): > pass > class Person(PersonBase): > pass > class Employee(EmployeeBase, Person): > pass > print ' Person MRO:', [i.__name__ for i in Person.mro() ] > print ' Employee MRO:', [i.__name__ for i in Employee.mro() ] > class Employee(Person, EmployeeBase): > pass > print 'Alt. Employee MRO:', [i.__name__ for i in Employee.mro() ] >=20 > just to be clear, IMHO the first way is the right way to do it if you > know the subclasses will never want to override the superclass. This > is the case of concrete classes in a templated abstract factory, for > example. The second way is probably what you want most other times. > In both cases all bets are off if you ever instanciate a *Base. >=20 > Clearer? Absolutely! However, the code generated with the base scheme is minimal: it defines entityName() plus the getters/setters for attributes and relationships, and these methods are almost never overriden in superclasses. So my opinion is finally that, *in the scope of the base classes needed by the mdl framework*, this does not really make much difference --tell me if I'm still missing an important point. -- S=E9bastien. > John Lenton (jo...@vi...) -- Random fortune: > Is that really YOU that is reading this? Is that really YOU asking this?-) |