From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mwb6X-0004oG-8K for qemu-devel@nongnu.org; Sat, 10 Oct 2009 08:31:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mwb6S-0004hZ-Fl for qemu-devel@nongnu.org; Sat, 10 Oct 2009 08:31:20 -0400 Received: from [199.232.76.173] (port=53185 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mwb6S-0004hM-9L for qemu-devel@nongnu.org; Sat, 10 Oct 2009 08:31:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23973) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mwb6R-0008LA-Pc for qemu-devel@nongnu.org; Sat, 10 Oct 2009 08:31:16 -0400 Subject: Re: [Qemu-devel] [PATCH v0 00/10]: More QObject conversions References: <1255037747-3340-1-git-send-email-lcapitulino@redhat.com> From: Markus Armbruster Date: Sat, 10 Oct 2009 14:31:12 +0200 In-Reply-To: <1255037747-3340-1-git-send-email-lcapitulino@redhat.com> (Luiz Capitulino's message of "Thu\, 8 Oct 2009 18\:35\:37 -0300") Message-ID: <877hv31ldb.fsf@pike.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org Luiz Capitulino writes: > Hi there, > > Here goes another set of conversions, just to keep the ball rolling. > > The first patch introduces a function called qobject_from_fmt(), which can > be used to build QObjects from a specified printf-like format. > > Most of its code was based on a Python function with similiar functionality, > as far as I could understand the license is compatible and I've added a > copyright notice. > > Is this the right procedure? > > Most patches are simple (as we aren't converting errors yet), except the > last ones. Which use qobject_from_fmt() and are very cool, hopefully they're > right too. :) > > PS: This series apply on top of my last 'Initial QObject conversion' series. > > Thanks. The separation of presentation from logic seems to work reasonably well so far. The separation involves building explicit data to be sent by a separate presentation function instead of printing right away. It's key that this data building code is about as legible and easy to maintain as the old, straightforward printing. qobject_from_fmt() helps with that, in my opinion. Of course, much "interesting" stuff remains, chiefly errors. Also any output that doesn't fit into the "run command to completion, report its result" mold (not sure we need that). We'll see how it goes. PS: Fun to see Greenspun's Tenth Rule in action once more.