From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:56727)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1SXZ4K-00045R-8C
	for qemu-devel@nongnu.org; Thu, 24 May 2012 10:31:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1SXZ4F-0002Af-A1
	for qemu-devel@nongnu.org; Thu, 24 May 2012 10:31:11 -0400
Received: from cantor2.suse.de ([195.135.220.15]:51919 helo=mx2.suse.de)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1SXZ4F-0002AQ-4J
	for qemu-devel@nongnu.org; Thu, 24 May 2012 10:31:07 -0400
Message-ID: <4FBE4625.9040703@suse.de>
Date: Thu, 24 May 2012 16:31:01 +0200
From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
MIME-Version: 1.0
References: <1337859784-24097-1-git-send-email-armbru@redhat.com>
	<4FBE2A59.3060701@suse.de> <m37gw1eknl.fsf@blackfin.pond.sub.org>
In-Reply-To: <m37gw1eknl.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new
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: Markus Armbruster <armbru@redhat.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, anthony@codemonkey.ws

Am 24.05.2012 16:08, schrieb Markus Armbruster:
> Andreas F=C3=A4rber <afaerber@suse.de> writes:
>=20
>> Am 24.05.2012 13:43, schrieb Markus Armbruster:
>>> Beware: second patch is the product of voodoo-coding.
>>
>> Hm, I don't like the voodoo. ;) I would rather expose a proper C API
>> like object_try_new(const char *, Error **) than opening up the TypeIm=
pl
>> internals to the public and hand-coding it everywhere.
>=20
> How does returning a TypeImpl * open up TypeImpl any more than
> type_register() already does?

type_register[_static]() operates on TypeInfo, not TypeImpl.

I consider TypeImpl an implementation detail of qom/object.c, but maybe
I'm mistaken.

>> similar error-catching scenario where I needed to check for class
>> existence in some qdev_try_* function.
>=20
> If this is a really common pattern, and object_try_new() really saves
> code, why not.
>=20
> Can't see why we need the Error **argument, though.  What kinds of
> different errors that do you envisage?  Where "different" means "actual
> callers care about the difference".

Well, I thought of class-doesn't-exist vs. out-of-memory. It would just
be to report different textual messages to the end user - as QMP error
response or as stderr output elsewhere. I have better OOM handling
somewhere down my TODO list, including a preallocated Error object. Main
reason is avoiding code duplication though.

Andreas

--=20
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC=
rnberg