On 2017-07-11 13:33, Markus Armbruster wrote: > Max Reitz <mre...@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 <mre...@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()). Max
signature.asc
Description: OpenPGP digital signature