[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-1.4] qom: Extend documentation on QOM method
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH for-1.4] qom: Extend documentation on QOM method concepts |
Date: |
Thu, 17 Jan 2013 12:55:12 -0600 |
User-agent: |
Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) |
Eduardo Habkost <address@hidden> writes:
> On Thu, Jan 17, 2013 at 08:31:50AM +0100, Andreas Färber wrote:
>> + * Alternatively, object_class_by_name() can be used to obtain the class and
>> + * its non-overridden methods for a specific type. This would correspond to
>> + * |[ MyClass::method(...) ]| in C++.
>
> I still wonder why resolving/saving/calling thie parent class method at
> runtime (using any of the two methods described above) is better than
> simply making the corresponding parent_class_method() function public,
> so it can be called directly by classes that override the method.
It's idiomatic from GObject.
I'm not sure I can come up with a concrete example but in the absense of
a compelling reason to shift from the idiom, I'd strongly suggest not.
Regards,
Anthony Liguori
>
> Is there any use-case where resolving the parent class implementation at
> runtime is really necessary?
>
>
>> + *
>> + * The first example of such a QOM method was #CPUClass.reset,
>> + * another example is #DeviceClass.realize.
>> */
>>
>>
>> --
>> 1.7.10.4
>>
>
> --
> Eduardo