qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 17/28] qapi: Allow true, false and null in sc


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v5 17/28] qapi: Allow true, false and null in schema json
Date: Wed, 01 Apr 2015 16:51:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Kevin Wolf <address@hidden> writes:

> Am 01.04.2015 um 13:03 hat Markus Armbruster geschrieben:
>> Kevin Wolf <address@hidden> writes:
>> 
>> > Am 01.04.2015 um 11:33 hat Markus Armbruster geschrieben:
>> >> Kevin Wolf <address@hidden> writes:
>> >> 
>> >> > Am 31.03.2015 um 22:09 hat Markus Armbruster geschrieben:
>> >> >> Kevin Wolf <address@hidden> writes:
>> >> >> 
>> >> >> > Am 24.03.2015 um 21:03 hat Eric Blake geschrieben:
>> >> >> >> From: Fam Zheng <address@hidden>
>> >> >> >> 
>> >> >> >> 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?
>> >> 
>> >> I guess JSON / Python was chosen as QAPI schema language to save us the
>> >> bother of defining a syntax and building the tools to work with it, like
>> >> an Emacs mode.  JSON's not exactly my favourite choice, but at least
>> >> it's not XML.
>> >> 
>> >> What we have now isn't JSON, but it's still a subset of Python, and the
>> >> Python tools work.  If we go beyond Python, they'll break.
>> >> 
>> >> If we decide to sacrifice these tools for readability, then we can just
>> >> as well replace the syntax entirely.  Preferably by something where I
>> >> don't have to put every identifier in quotes.
>> >> 
>> >> In short, you're welcome to hack up qapi.py some more for schema
>> >> readability, but either keep Emacs Python mode working, or provide a
>> >> replacement :)
>> >
>> > What features does this Python mode provide that you use?
>> 
>> Syntax highlighting, automatic indentation, possibly more I rely on
>> without noticing.  My fingers know, but they don't talk.
>> 
>> > For the JSON schema, the only thing I really use from the editor is
>> > syntax highlighting, and that shouldn't be bothered by an addition like
>> > this (in vim it doesn't hurt anyway). I also don't use any other Python
>> > tools, though I'm not sure that none exist that would make sense with
>> > the schema.
>> >
>> > So if there are practically relevant advantages in being real Python
>> > code, then we need to consider that, of course. That's why I was asking.
>> > But if there aren't, it's just an arbitrary restriction that could be
>> > removed.
>> 
>> If we decide to revise the decision to borrow existing syntax and roll
>> our own instead, let's 'make' 'our' 'own' 'syntax' 'not' 'suck'.
>> 
>> Anyway, we got bigger fish to fry right now.
>
> Okay, I got it. Asking me to create a completely new syntax and the
> generator for it is the longhand version for "no".

It's advice, not a proactive NAK.

Anyway, let's get Eric's series in, and crack the introspection problem
before we start even more QAPI generator projects.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]