Re: [Qemu-devel] [PATCH 04/21] qobject: add quint type

["Marc-André Lureau" <mlureau@redhat.com>]

Hi

----- Original Message -----
> On 03/13/2017 02:15 AM, Markus Armbruster wrote:
> > Eric Blake <eblake@redhat.com> writes:
> > 
> >> On 03/11/2017 07:22 AM, Marc-André Lureau wrote:
> >>> The type is not used at all yet. Add some tests to exercice it.
> >>
> >> s/exercice/exercise/
> >>
> >> I wonder if we need this patch at all.
> >>
> >> I've been thinking about a possible alternative representation, such
> >> that a single QInt type can cover _both_ signed and unsigned types, by
> >> having QInt track a sign bit bool in addition to a uint64_t value.
> >>
> 
> > You say you've been thinking about extending QInt's range to cover
> > uint64_t.  I've been thinking even more radically: replace both QInt and
> > QFloat by QNumber.  This is how JSON *actually* works.
> > 
> > The new QNumber type provides constructors from double, int64_t and
> > uint64_t.  It also provides conversion functions to double, int64_t and
> > uint64_t.  The latter two can fail.
> 
> Interesting - I like it, as it takes my idea and goes one step further.
> You'd want to track 64 bits of precision rather than just 53, when the
> input was integral, but the idea seems to have some merit (we have some
> special case in the testsuite for what happens in alternates with
> various combinations of 'number' vs. 'int' that may need tweaking when
> they are no longer distinguishable as QInt vs QFloat, but that's not too
> onerous).
> 

I wonder the benefits from hiding the real type behind a QNumber "superclass", then having to type check at a lower level. QType is not only used for json, so I see some benefits from having a bit stricter type declaration and compile-time check. But I don't have a very good idea of what it would mean to have a generic QNumber type, I could try to implement it to have a more informed opinion.

> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 
>