help page suggestion: indication of integral values vs real numbers Indicate in documentation whether "numbers" can be non-integral

[suggestion] is a pointless meta-tag; fixed grammar and formatting; reduced verbosity

Source Link

edit approved Mar 12, 2014 at 13:05

michaelb958--GoFundMonica

1k
6
18

number "number" is an very ambiguous term.

It would be helpful if there was an indication of values that can return as Integral or non-integral.?

In a javascript contextFor developers in more dynamically-typed languages like JavaScript, this is not an issue,issue; but most devs, myself includedwhen using more statically-typed languages like C#, developers need to know when to use an int/long vs double/decimal in orderint or long should be used, as opposed to properly define schemas and objectsa double.

a possible solutionIt would be to follow MS format and indicate with an integer flaghelpful if values that can be non-integral were more clearly indicated.

updateUpdate::

yesYes, I understand that you are returning a 'number'"number" in JSON, so technically the spec is correct. butBut what good does that do your audience?

Should I make every object field and database column a float so it doesn't break unexpectedly because I guessed wrong what datatype I should use?

Sure, I can guess, and correctly in most cases guess correctly, but you are not guessing and your data fields are not all floats - are you picking up what I am putting downis that really the best thing possible?

"number" is of questionable value to all but the most trivial applications of the apiAPI, and downgrading the spec because of the limitations of transport is a mistake in my opinion.

number is an very ambiguous term.

It would be helpful if there was an indication of values that can return as non-integral.

In a javascript context this is not an issue, but most devs, myself included, need to know when to use an int/long vs double/decimal in order to properly define schemas and objects.

a possible solution would be to follow MS format and indicate with an integer flag.

update:

yes, I understand that you are returning a 'number' so technically the spec is correct. but what good does that do your audience?

Should I make every object field and database column a float so it doesn't break unexpectedly because I guessed wrong what datatype I should use?

Sure, I can guess, and correctly in most cases, but you are not guessing and your data fields are not all floats - are you picking up what I am putting down?

number is of questionable value to all but the most trivial applications of the api and downgrading the spec because of the limitations of transport is a mistake in my opinion.

"number" is an very ambiguous term. Integral or non-integral?

For developers in more dynamically-typed languages like JavaScript, this is not an issue; but when using more statically-typed languages like C#, developers need to know when an int or long should be used, as opposed to a double.

It would be helpful if values that can be non-integral were more clearly indicated.

Update:

Yes, I understand that you are returning a "number" in JSON, so technically the spec is correct. But what good does that do your audience?

Should I make every object field and database column a float so it doesn't break unexpectedly because I guessed wrong what datatype I should use? Sure, I can guess, and in most cases guess correctly, but is that really the best thing possible?

"number" is of questionable value to all but the most trivial applications of the API, and downgrading the spec because of the limitations of transport is a mistake in my opinion.