Yes, I remembered that, but Kem’s tests are ancient and new benchmarks as of Xojo 2021 would be very helpful.
I’m mostly interested in the speed of JSON lookups through a child or two vs making a dictionary of the child once, then looking up in the child dictionary in my loops. The former makes code cleaner, but I suspect the latter is much faster.
That’s the main reason I haven’t bothered trying it.
Looks like I have in about a dozen projects, all originally dating back years, so at the time I would have used it because of the performance advantages. If I had to refactor to something else, it would not be a big deal to me.
New benchmarks comparing the various JSON and Dictionary alternatives since Xojo 2021 would be enlightening though…
That’s well out of date now, and JSONItem is substantially faster.
So I am about to switch to using a new JSON library which can do more.
The new class should cover > 90% of both old JSONMBS and JSONItem to be a drop in for both.
And it gets a few new features like iterators.
The Convert function will stay of course for @David_Cox.
You may be thinking of The ZAZ: JSON Performance Tests Round 2 which is very out of date these days. I always intended to run another set of tests with Einhugur, but never got around to it. These days, you can’t really go wrong, but I suspect MBS is still the performance king if you need the absolute fastest parsing.
< Instead of derailing this thread, I have created a new one. My apologies, Christian >
Updated JSON Speed Tests Project
or not
in fact i use the 3 of the tests, i’m suprised mbs is not way faster than build in
We use it for all JSON processing…
…and they way we are using it is according to the example project we’ve created with you: JSONItem clone
So basically it is the replacement for Xojo’s JSONItem which we are using via your Plugins.
As long as that example project continues to work “as it is” it’s probably fine for us 
For JSONItem_MBS, you would need to remove this in the constructor since the parsing constructor now raises an exception:
If (mJSON.Handle = 0) or (mJSON.ParseError <> "") Then
Raise New JSONException("JSONMBS ParseError: " + mJSON.ParseError, mJSON.Handle)
End If
and for FromJSON, you need to handle the new types:
Case JSONMBS.kTypeFalse
Return False
Case JSONMBS.kTypeNumber
If pJSON.IsInt64 Then Return pJSON.ValueInteger
Return pJSON.ValueDouble
Case JSONMBS.kTypeString
Return pJSON.ValueString
Case JSONMBS.kTypeTrue
Return True
replaced with:
Case JSONMBS.kTypeDouble
Return pJSON.ValueDouble
Case JSONMBS.kTypeInt64
Return pJSON.ValueInt64
Case JSONMBS.kTypeUInt64
Return pJSON.ValueUInt64
Case JSONMBS.kTypeString
If pJSON.IsInt64 Then Return pJSON.ValueInt64
If pJSON.IsNumber Then Return pJSON.ValueDouble
Return pJSON.ValueString
Case JSONMBS.kTypeSingle
Return pJSON.ValueDouble
or just use JSONMBS as JSONItem replacement itself.
With JSON, something is missing : the currency type.
This is strange because using amounts is very common.
There are 3 ways to use currencies : convert them to double with the risk of having something such as : 125.589999999…
Convert them to string to get “125.59” (with quotes that is quite strange for an amount).
The 3rd way is to build the json as a string and do what we want.
I’ll like to have something like
myJson.value(“amount”) = myCurrencyValue and getting : {…“amount” : 125.59, …}
Or the fourth way, which I’ve seen most often, is to treat the currency as an integer. Multiply by 100 for storage, and divide by 100 for displaying to the user.
Our json class stores numbers with string representation.
So a currency can go in and out without trouble.
heu… if this json is in reply of an api, you never know who and what will treat it. (“hey guy, don’t forget to divide this amount by 100 !..”)
Gag : with the same json built with a postgreslql json function :
Xojo jsonitem.tostring gives : “theAmount”:1572078.99,…
Postman gives : “theAmount”:1572078.9899999999907,…
It is, and APIs are where I’ve seen this. All environments will have this problem. JSON is more-or-less typeless. So using an integer is a reliable way to avoid the problem entirely.
That said, it sure would be nice if Xojo were to apply some sort of formatting rules so you would get something like what you see in Postman. But Xojo is aiming for accuracy, and doubles aren’t very accurate. Which… again… is why integers are a common solution.
I had one error (in three locations). I now have to turn my Variant into a String before I can use it to create a New JSONMBS(String) , but that’s OK.
JSONMBS in 23.5pr1 does not have the “Value” methods, e.g. jsonMbsObject.Value("key") = "value"
Sure?
ist listed on the website!?
Are you sure the new plugin is loaded?
Yes, the Set-ters for .Value are not (yet) available.
use JSONMBS as JSONItem replacement itself
So one can’t use it as a replacement (by renaming JSONItem → JSONMBS).
Additionally: MBS.VersionNumber returns 23.4 (expected: 23.5).
So one can’t use conditional compilation for testing the changes while still using 23.4 for productive usage:
#if MBS.VersionNumber < 23.5 then
'existing productive (shared) code
#else
'modified to work with MBS 23.5
#endif
I know of the version number problem. Fixed for pr2, but confused a few users.
The Value setter works for me already:
Dim j As New JSONMBS
j.Value("test") = 1234