From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Me9Fq-0005oB-Mj
	for qemu-devel@nongnu.org; Thu, 20 Aug 2009 11:08:42 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Me9Fl-0005lT-4x
	for qemu-devel@nongnu.org; Thu, 20 Aug 2009 11:08:42 -0400
Received: from [199.232.76.173] (port=41257 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Me9Fl-0005lP-1B
	for qemu-devel@nongnu.org; Thu, 20 Aug 2009 11:08:37 -0400
Received: from mx1.redhat.com ([209.132.183.28]:54829)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <lcapitulino@redhat.com>) id 1Me9Fk-0007Q3-FB
	for qemu-devel@nongnu.org; Thu, 20 Aug 2009 11:08:36 -0400
Date: Thu, 20 Aug 2009 12:08:28 -0300
From: Luiz Capitulino <lcapitulino@redhat.com>
Message-ID: <20090820120828.5c5c66e5@doriath>
In-Reply-To: <4A8D589D.2060208@redhat.com>
References: <1250723280-3509-1-git-send-email-lcapitulino@redhat.com>
	<1250723280-3509-5-git-send-email-lcapitulino@redhat.com>
	<4A8D0202.7020803@redhat.com> <20090820105756.1bd958c8@doriath>
	<4A8D589D.2060208@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 04/29] Introduce QDict
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org

On Thu, 20 Aug 2009 17:07:25 +0300
Avi Kivity <avi@redhat.com> wrote:

> On 08/20/2009 04:57 PM, Luiz Capitulino wrote:
> > On Thu, 20 Aug 2009 10:57:54 +0300
> > Avi Kivity<avi@redhat.com>  wrote:
> >
> >    
> >> On 08/20/2009 02:07 AM, Luiz Capitulino wrote:
> >>      
> >>> QDict is a high-level dictionary data type that can be used to store a
> >>> collection of QObjects. A unique key is associated with only one
> >>> QObject.
> >>>
> >>> The following functions are available:
> >>>
> >>> - qdict_new()    Create a new dictionary
> >>> - qdict_add()    Add a new 'key:object' pair
> >>>
> >>>        
> >> qdict_put() is both symmetrical with qdict_get(), and also conveys the
> >> fact that you can replace an existing key/value.
> >>      
> >   Would it be useful in the current Monitor code? If so, how?
> >    
> 
> The current code, no, but once we read qdicts from the monitor, you need 
> to be able to handle { a: 1, a: 2 }.

 qdict_add() will refuse to add an existing key, but I can change
it to replace instead.

 Would this be enough?

> >>> + */
> >>> +int qdict_get_int(const QDict *qdict, const char *key)
> >>> +{
> >>> +    QObject *obj = qdict_get_obj(qdict, key, QTYPE_QINT);
> >>> +    return qint_to_int(qobject_to_qint(obj));
> >>> +}
> >>>
> >>>        
> >> This assumption does not hold if the dict came from a user.
> >>      
> >   Then the user has to know what he or she is doing. :)
> >    
> 
> They don't, as a rule.

 That's why there's an assert() there. :)

> >   The problem with high-level functions that receive a QObject
> > but return a plain int is: what do you return if QObject is
> > not an QInt?
> >    
> 
> Pass a default value to return.

 Looks a good solution, although I think both cases are useful.

 For most handlers, for example, the monitor code _must_ push
the key specified in qemu-monitor.hx into the dictionary. Not
doing this is a bug.

 But we also support optional keys, which may or may not be
pushed into the dictionary.

 We need two functions then and this also applies to QString.