From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46566)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1YdE45-00054V-60
	for qemu-devel@nongnu.org; Wed, 01 Apr 2015 04:31:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1YdE41-0000bB-6N
	for qemu-devel@nongnu.org; Wed, 01 Apr 2015 04:31:57 -0400
Received: from mx1.redhat.com ([209.132.183.28]:38608)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1YdE41-0000b4-1j
	for qemu-devel@nongnu.org; Wed, 01 Apr 2015 04:31:53 -0400
Date: Wed, 1 Apr 2015 10:31:50 +0200
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20150401083150.GB3593@noname.str.redhat.com>
References: <1427227433-5030-1-git-send-email-eblake@redhat.com>
	<1427227433-5030-18-git-send-email-eblake@redhat.com>
	<20150331152359.GC4748@noname.redhat.com>
	<87sicl2akl.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87sicl2akl.fsf@blackfin.pond.sub.org>
Subject: Re: [Qemu-devel] [PATCH v5 17/28] qapi: Allow true,
 false and null in schema json
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: famz@redhat.com, lcapitulino@redhat.com, qemu-devel@nongnu.org, wenchaoqemu@gmail.com

Am 31.03.2015 um 22:09 hat Markus Armbruster geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
> > Am 24.03.2015 um 21:03 hat Eric Blake geschrieben:
> >> From: Fam Zheng <famz@redhat.com>
> >> 
> >> In the near term, we will use it for a sensible-looking
> >> 'gen':false inside command declarations, instead of the
> >> current ugly 'gen':'no'.
> >> 
> >> In the long term, it will allow conversion from shorthand
> >> with defaults mentioned only in side-band documentation:
> >>  'data':{'*flag':'bool', '*string':'str'}
> >> into an explicit default value documentation, as in:
> >>  'data':{'flag':{'type':'bool', 'optional':true, 'default':true},
> >>          'string':{'type':'str', 'optional':true, 'default':null}}
> >
> > FWIW, I don't think that's a very friendly syntax for humans, it's a bit
> > verbose. But that's no reason not to allow true/false/null, of course.
> 
> Here's my current thinking.
> 
> Longhand:
> 
>     # mandatory
>     'name': { 'type': 'str' }
>     # optional, with a default
>     'flag': { 'type': 'bool', 'default': true }
>     # optional, no default
>     'string': { 'type': 'str', 'default': null }
> 
> Presence of 'default' implies optional.
> 
> Equivalent shorthand, if any:
> 
>     'name': 'str'
>     '*string': 'str'

A nice shorthand for defaults would be:

    '*name': 'str' = 'default'

Though that would be neither valid JSON nor Python any more. Do we
actually rely on this property anywhere or is it only parsed by the QAPI
generator anyway and we can extend the language in such ways?

Kevin