From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1aQj-0001U3-HE for qemu-devel@nongnu.org; Fri, 10 Jan 2014 06:39:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1aQb-00082E-4Y for qemu-devel@nongnu.org; Fri, 10 Jan 2014 06:39:13 -0500 Received: from mail-ea0-x234.google.com ([2a00:1450:4013:c01::234]:42101) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1aQa-000827-TZ for qemu-devel@nongnu.org; Fri, 10 Jan 2014 06:39:05 -0500 Received: by mail-ea0-f180.google.com with SMTP id f15so2017915eak.11 for ; Fri, 10 Jan 2014 03:39:03 -0800 (PST) Sender: Paolo Bonzini Message-ID: <52CFDBD1.5030705@redhat.com> Date: Fri, 10 Jan 2014 12:38:57 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1389197382-25085-1-git-send-email-imammedo@redhat.com> <52CD7BBF.3030202@redhat.com> <20140108175159.029e5f9e@nial.usersys.redhat.com> <52CD8BD7.8070706@redhat.com> <20140110122810.7d34b120@thinkpad> In-Reply-To: <20140110122810.7d34b120@thinkpad> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/5] -object/object-add support custom location and 2nd stage initialization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: aliguori@amazon.com, sw@weilnetz.de, mjt@tls.msk.ru, qemu-devel@nongnu.org, lcapitulino@redhat.com, blauwirbel@gmail.com, stefanha@redhat.com, afaerber@suse.de, rth@twiddle.net Il 10/01/2014 12:28, Igor Mammedov ha scritto: >> > Regarding the "overloading" of the realize name, I was against it in >> > previous discussion and I still am (I was in favor of something like >> > UserCreatable and naming the method "complete" or "construct"), but I >> > didn't want to sound too negative. :) > issue with naming interface as CommandLine or UserCreatable is that, it could > be used not only by CLI/user but also it could be used internally. For example > see "[PATCH 3/5] virtio_rng: use object_realize interface instead of calling > backend API", where default backend is created by frontend. I see. Yes, with something like UserCreatable, you would not have that patch. Instead, UserCreatable's complete method would redirect to the backend-specific API. BTW, note that UserCreatable's complete method should take a UserCreatable (or whatever the name is) as the first parameter, not an Object. This would affect that patch, too. > how about naming it for what it is: object-2nd-stage-init That would also work for me (TwoStageConstructable or something like that). One advantage of UserCreatable is that -object/object_add could check for it and reject creation of objects that are not meant for command-line instantiation. You could do the same for TwoStageConstructable, but it would look weird to define an object as two-stage constructable with an empty complete method. With a name like UserCreatable, instead, it would be quite natural to do this: void user_creatable_complete(UserCreatable *uc, Error **errp) { UserCreatableClass *ucc = USER_CREATABLE_GET_CLASS(uc); if (ucc->complete) { ucc->complete(uc, errp); } } > neutral object-complementary-interface that could be extended later with > another methods No, we don't want a hodge-podge interface that's basically UserCreatable except in the name. :) Paolo