[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 13:03:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
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.