From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:35912)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1TvucP-0003Q5-Sg
	for qemu-devel@nongnu.org; Thu, 17 Jan 2013 13:55:19 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1TvucO-0006gC-E6
	for qemu-devel@nongnu.org; Thu, 17 Jan 2013 13:55:17 -0500
Received: from mail-ie0-f170.google.com ([209.85.223.170]:48224)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1TvucO-0006fz-94
	for qemu-devel@nongnu.org; Thu, 17 Jan 2013 13:55:16 -0500
Received: by mail-ie0-f170.google.com with SMTP id k10so5380893iea.29
	for <qemu-devel@nongnu.org>; Thu, 17 Jan 2013 10:55:15 -0800 (PST)
From: Anthony Liguori <anthony@codemonkey.ws>
In-Reply-To: <20130117164856.GO10683@otherpad.lan.raisama.net>
References: <1358407910-6031-1-git-send-email-afaerber@suse.de>
	<20130117164856.GO10683@otherpad.lan.raisama.net>
Date: Thu, 17 Jan 2013 12:55:12 -0600
Message-ID: <87pq13abcf.fsf@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH for-1.4] qom: Extend documentation on QOM
	method concepts
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eduardo Habkost <ehabkost@redhat.com>, Andreas =?utf-8?Q?F=C3=A4rber?= <afaerber@suse.de>
Cc: qemu-devel@nongnu.org

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Thu, Jan 17, 2013 at 08:31:50AM +0100, Andreas F=C3=A4rber wrote:
>> + * Alternatively, object_class_by_name() can be used to obtain the clas=
s and
>> + * its non-overridden methods for a specific type. This would correspon=
d 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.
>>   */
>>=20=20
>>=20=20
>> --=20
>> 1.7.10.4
>>=20
>
> --=20
> Eduardo