[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v0 00/10]: More QObject conversions
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] [PATCH v0 00/10]: More QObject conversions |
Date: |
Sun, 11 Oct 2009 11:48:34 -0300 |
On Sat, 10 Oct 2009 14:31:12 +0200
Markus Armbruster <address@hidden> wrote:
> Luiz Capitulino <address@hidden> 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.
Yes, it helps, although adding more abstraction layers usually makes
things more complex.. That is, this is never going to be as simple as
directly calling monitor_printf().
> Of course, much "interesting" stuff remains, chiefly errors.
Yes, and errors are more complicated than regular output because
sometimes we have something like:
command_handler()
func1()
func2()
func3() <--- calls monitor_printf() on error
Also, an error condition has to be differently handled from regular
output, so that the protocol can emit it as an error.
I've implemented QError, which (IMHO) is a good enough solution
for the problem. Will submit it as soon as I get more feedback
on this last series.
> 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.
Do you have an existing example?
> PS: Fun to see Greenspun's Tenth Rule in action once more.
Let's rewrite qemu in lisp then. :-)
[Qemu-devel] [PATCH 07/10] monitor: Convert do_info_migrate() to QObject, Luiz Capitulino, 2009/10/08
[Qemu-devel] [PATCH 09/10] monitor: Convert pci_device_hot_add() to QObject, Luiz Capitulino, 2009/10/08
[Qemu-devel] [PATCH 10/10] monitor: Convert do_pci_device_hot_remove() to QObject, Luiz Capitulino, 2009/10/08
Re: [Qemu-devel] [PATCH v0 00/10]: More QObject conversions, Markus Armbruster, 2009/10/10
- Re: [Qemu-devel] [PATCH v0 00/10]: More QObject conversions,
Luiz Capitulino <=