Re: [Qemu-devel] [PATCH v0 00/10]: More QObject conversions

[Luiz Capitulino]

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. :-)