Yes that’s exactly what “most” means right?
Like i said before, i’m not against any feature request or such. It’s all about standards are better to use, but i’ve never mentioned they are the only way.
Change the code to add the currency value as a string instead and it will all work just fine.
var c as Currency = 1.935
var j as new JSONItem
j.Value( "c" ) = c.ToString
var jString as string = j.ToString // {"c":"1.935"}
j = new JSONItem( jString )
c = j.Value( "c" ) // 1.935
We are talking about decimal values, not strings. Receiving a string in some APIs would render as a bad formed JSON error at the backend.
The problem, as I mentioned before, is that JSON does not define a “currency” type value, so limiting the decimal places in a float still makes it a float. The setting Xojo offered before was an illusion.
Send the float, or send a string if the API will allow it, or send a string or an integer if you control both ends. Artificially limiting the decimal places is of no value, practically speaking.
1 Like
We’re not talking about JSON at this point, but Xojo engine to handle JSON serialization. Xojo stores currencies, and should render them as proper JSON as “value”: 1.2345
That is no different than "value" : 1.2344999999999999, which is how it’s represented as a double.
Again, I’m talking about Currency SOURCE, not a DOUBLE.
A Currency source should render as expected.
So a special type to render decimal values.
1 Like
you are right, my xojo version does not support it 
1 Like
Dim c As Currency = 1.2345
dim d as Double = c
Dim j As New JSONItem
j.Value("test") = d // can't use c here!
Dim m As New JSONMBS
m.Value("test") = c
MessageBox j.ToString+EndOfLine+m.toString
// shows {"test":1.2344999999999999307} vs {"test":1.2345} since we store currency exactly.
So you can’t put in currency to JSONItem right away as that raises an exception.
But JSONMBS converts currency to number value for JSON with precision.
So you do it correctly? Good. I hope Xojo do it too.
As of this moment, this bug is up voted by 22 people. And it has a pro plus tag. But, it does not have a milestone tag yet.
It will be interesting to sit back and see if this is addressed in the next release or not.
well, looks like that you are WRONGLY asuming that JSON uses doubles…
No it does NOT, Json defines a number data type. This value can have any number of decimal places as the user or the app Wants or needs, even can have an exponent.
If it allowed to create a valid JSON as needed by the user/APIs, it was actually useful and in fact, an integral part of a decent Json string creator.
https://www.ecma-international.org/publications-and-standards/standards/ecma-404/
1 Like
JSON doesn’t “use” anything, it represents data. A “number” can be an integer, a float, or an acceptable representation of one of those, as defined by the standard. How it’s interpreted is up to the receiving system.
There is no “currency” type defined in JSON, i.e., an integer, dot, and limited number of decimal places, so anything with a decimal point is going to be interpreted as a float. The receiving system may convert that to a currency type, but that will involve rounding either way. In that respect, there is absolutely no difference between sending 1.2345 and 1.234499999999.
More, many systems will correctly interpret a string that contains a representation of an expected value, so if you really want to limit the decimal places, that is often an acceptable alternative.
Finally, I’m quite familiar with the JSON standard since, as you might not know or perhaps forgotten, I wrote a replacement for JSONItem many years ago.
5 Likes
Well, you were pretty insistent on that values must be doubles.
No one said it does. Even rick explained to you that the “currency” bug was ABOUT XOJO not allowing to use the XOJO CURRENCY DATA TYPE to build the Json
That is NOT always true, and that is exactly what this thread is about. The receiving system could especify a fixed number of decimal places and dont do ANY rounding. As Json allow any number of decimal places, it is ok for a system to set an API rule as is incompliance with the Json Standard. Xojo as a tool should provide the means to comply with those special rules.
1 Like
Usually the backend propose a protocol. It says what it accepts and how it handles acceptable data. It may or may not accept strings and convert to numbers internally, it may accept long decimals and use as is or truncate or round at some point. Who defines it is the API designer, not the JSON standard that is only a media standard.
What people say in those definitions are like:
field name: balance
field type: numeric with 2 decimals for cents
note: if pass more than 2 decimals they will be truncated at 4 decimal digits
The problem is if the designer does not include the “note”, so no one knows exactly the behavior, so passing what’s exactly on the “field type” should solve the problem, always no more than 2 decimals as: nnnnn.nn
Those kind of things.
Another thing is, unnecessary storage and traffic of useless data.
[ 123.1234 , 234.56, …] are much better than [123.1234000000000000032 , 234.560000000000000076, …]
It’s unusual seeing the second type.
And as already said, people handle it with special types, like Christian did handling Currency in Xojo with his JSONMBS, and people using Swift used to using NSDecimalNumber, so they could send any desired value.
Yup, and your JSONItem_MTC supports a customizable .DecimalFormat with a default of -0.0############## 
That works just fine and beatufilly with the latest Xojo Version.
Besides the above discussion about a Double-Value meaning the same, Currencies as numbers or strings, …
…even if it’s just a Developer’s silly idea wanting to have the JSON output formatted in a defined way (e.g. a number value with 3 decimal places - because it’s just much more readable than a double value) - then there is no way to achieve that with a current Xojo Version (and without Plugins, or own JSON implementations).
That’s basically what this is all about. Such a basic feature/functionality that used to be possible, and got “deprecated (*)” with no replacement.
(*) And “deprecated” doesn’t mean “broken” or “removed”. Existing Code using Xojo’s JSONItem and it’s .DecimalFormat compiles and runs just fine… but produces a highly unexpected (and in some cases unwanted/undesired) output. Then better remove it and cause a compile error compared to suddenly have a different output (which silently may or may not lead to none, minor or big issues).
4 Likes
I agree with that.
1 Like
Building business software is not a good use case for this request.
The primary use of JSON is to transfer data between applications, operating systems and environments. And in that respect you can only rely on two things to preserve accuracy - integers for storage and strings to guarantee display across environments.
I spent over thirty years writing and designing financial systems for banks around the world - trading systems, portfolio management systems, commission calculation systems etc… And I can recall a few that fell over because of decimal usage, but none that used the usual methods - integers and strings.
3 Likes