Re: [Qemu-devel] [PATCH v4 2/5] qapi: Add qobject_is_equal()

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3139 bytes --]

On 2017-08-14 11:07, Markus Armbruster wrote:
> Max Reitz <mreitz@redhat.com> writes:
> 
>> On 2017-07-11 13:33, Markus Armbruster wrote:
>>> Max Reitz <mreitz@redhat.com> writes:
>>>
>>>> First of all, OK, you don't want QNum(42.0) to equal QNum(42) at all (at
>>>> least not right now and in the foreseeable future).
>>>> You're the maintainer, so you decide, so I'll go along with it. :-)
>>>>
>>>> Now, let's follow up with my therefore rather useless commentary:
>>>>
>>>> (Feel free to disregard, because honestly, I can see how replying to
>>>> most of the points I'm asking isn't really worth the time...)
>>>
>>> When I use the authority entrusted to maintainers, I feel obliged to at
>>> least explain my reasoning.  Besides, putting my reasoning in words
>>> tends to lead me to new insights.
>>
>> And I am indeed very grateful for that. :-)
>>
>>>> On 2017-07-10 11:17, Markus Armbruster wrote:
>>>>> Max Reitz <mreitz@redhat.com> writes:
>>>>>
>>>>>> On 2017-07-06 16:30, Markus Armbruster wrote:
>>
>> [...]
>>
>>>>> The only way to add unsigned integers without breaking QMP compatibility
>>>>> is to make them interchangeable with signed integers.  That doesn't mean
>>>>> you get to make floating-point numbers interchangeable with integers
>>>>> now.
>>>>
>>>> Again, begs the question why QNum covers floating point numbers then and
>>>> why this very fact is not documented in qnum.c.
>>>
>>> What kind of documentation would you like to see?
>>
>> It would be good to note that the QNum type is not meant to be a
>> completely uniform way to handle JSON numbers (e.g. if the user provides
>> something with a decimal point but you need an integer, QNum will not do
>> that conversion for you).
>>
>> It is (English indirect speech is broken badly) just meant to
>> encapsulate the different variants a number can be represented in, but
>> you're still generally supposed to read it out the way it was put in
>> (exceptions apply, see signed/unsigned and qnum_get_double()).
> 
> Can we distill this into text that could become an actual patch?  Let me
> try.
> 
>     QNum encapsulates how our dialect of JSON fills in the blanks left
>     by the JSON specification (RFC 7159) regarding numbers.
> 
>     Conceptually, we treat number as an abstract type with three
>     concrete subtypes: floating-point, signed integer, unsigned integer.
>     QNum implements this a discriminated union of double, int64_t,
>     uint64_t.
> 
>     The JSON parser picks the subtype as follows.  If the number has a
>     decimal point or an exponent, it is floating-point.  Else if it fits
>     into int64_t, it's signed integer.  Else if it first into uint64_t,
>     it's unsigned integer.  Else it's floating-point.
> 
>     Any number can serve as double: qnum_get_double() converts under the
>     hood.
> 
>     An integer can serve as signed / unsigned integer as long as it is
>     in range: qnum_get_try_int() / qnum_get_try_uint() check range and
>     convert under the hood.
> 
> What do you think?

Sounds very good to me, thanks!

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]