From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYvwP-0006sX-Ei for qemu-devel@nongnu.org; Mon, 07 Sep 2015 08:54:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYvwK-0006T4-Rd for qemu-devel@nongnu.org; Mon, 07 Sep 2015 08:54:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYvwK-0006Sw-M5 for qemu-devel@nongnu.org; Mon, 07 Sep 2015 08:54:28 -0400 References: <1440590594-5514-1-git-send-email-berrange@redhat.com> <1440590594-5514-2-git-send-email-berrange@redhat.com> <55E72154.7070404@suse.de> <20150903154952.GK31547@redhat.com> <87oahjmpaw.fsf@blackfin.pond.sub.org> <55E87831.5040405@suse.de> <87a8t3l9lq.fsf@blackfin.pond.sub.org> <20150903170914.GX31547@redhat.com> <55E88183.1010706@suse.de> <20150903172508.GY31547@redhat.com> <87lhcmiseu.fsf@blackfin.pond.sub.org> From: Paolo Bonzini Message-ID: <55ED8900.5090804@redhat.com> Date: Mon, 7 Sep 2015 14:54:24 +0200 MIME-Version: 1.0 In-Reply-To: <87lhcmiseu.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 1/7] qom: allow properties to be registered against classes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , "Daniel P. Berrange" Cc: =?UTF-8?Q?Andreas_F=c3=a4rber?= , qemu-devel@nongnu.org On 04/09/2015 08:56, Markus Armbruster wrote: >> > >> > Personally I'd prefer to see us focus on just solving the simple >> > cases first, so we don't end up stuck arguing over the hard >> > cases and holding up potential quick wins ! > That's a sensible approach when the solutions to the simple cases are > likely to stand regardless of whether and how we later crack the hard > cases. I guess it's sensible here. Let me explain. > > I prefer defining properties in static data rather than code, because > reasoning over static data is so much easier. If we can find a way to > do that even for the hard cases, lovely. If we can't, then I'd still > prefer the softer cases done in data. Two mechanisms instead of one > (bad), but the vast majority of cases becomes simpler (good). I agree. Plus, we already have two mechanisms anyway "thanks" to qdev static properties, so it's a net improvement. paolo