On Fri, Jul 30, 2010 at 12:52:31PM +0100, Simon McVittie wrote: > On Fri, 30 Jul 2010 at 09:45:14 +0200, Matthias Berndt wrote: > > I understand it as the instance method for an object instance is > > declared on the class. Declaring the method on the instance data > > structure seems more logical to me. I mean something like this: > > Instance methods (as they're normally understood, e.g. as seen in C++ or Java) > are defined as part of the class, because each instance of the same class has > the same implementation of each method. So GObject is more flexible. > If you put them in the object struct, every time you instantiated a Foo object > you'd have to fill in the bar function pointer to point to the same > implementation; by putting them in the class struct, this becomes unnecessary. My question was more about "How is it correct for GObject?" and less about "How ist it efficent?". I'm sorry if I wasn't able to place a clear question. > The fact that there's a class struct and a separate object struct is an > artefact of the way GObject implements object-orientation in C; other OO > runtimes written in C, like (the C implementation of) Python, work very > similarly. The same sort of thing happens behind the scenes in C++, but you > don't see it in the source code because the compiler takes care of it. I do not know enough about Python, but -- for example -- in Ruby you are able to replace methods on a single object instance and not for the whole class. So it seems to me to be handled more like the object struct. Are there any disadvantages putting methods into the object struct except more work for instantiation and an increased memmory usage? Is anyone or anything relying on the class struct for virtual methods? Is "virtual methods a defined in the class struct" such a hugh convention that is shouldn't be ignored? Are the addtional impacts using the object struct. Matthias
Attachment:
pgpwvYLtyQRo7.pgp
Description: PGP signature