Dictionary or JSONItem, is there a difference?

I have read through all of the threads, most of which are older now, concerning JSONItem and its performance and capabilities. The capabilities have evolved over time, and if I am intending to use strings for keys, I’m wondering if there is any benefit of ever converting JSONItem to a Dictionary or vice versa.

If I decided to solely use JSONItem going forward, and never really use Dictionary, are there performance implications I need to be aware of? It seems, other than requiring strings for keys, there is not any difference I can really see between Dictionary and JSONItem.

Am I missing something? Are there circumstances where one should be favored over the other, when keys will be strings?

I think Dictionary’s keys are case insensitive, where JSONItem is case sensitive. Otherwise I think one is a subclass of the other.

1 Like

Only if you plan to interact with JSON at all. Parsing JSON into a Dictionary forces you to deal with variants and introspection just to do simple things.

If you’re going to have input or output to JSON use JSONItem.
If your systems will be entirely Xojo code, Dictionary has the advantage of non-string keys.

2 Likes

Thanks Tim. Do you think, at this point, the performance between the two are the same?

I don’t have any test data. I believe JSONItem was simply reworked to wrap around the Xojo.Core.Dictionary and ParseJSON stuff, so I think they’re roughly the same. I don’t have any sources, links, or tests that can confirm the suspicion for you.

Quickly searching Google for the release notes on when this change occurred is not proving fruitful, so I cannot tell you in which version JSONItem was updated or provide specifics.

1 Like

2021R1 was when JSONItem was changed to use Dictionaries & Parse/Generate JSON under the hood.

1 Like

Right. So IF there is a performance difference, it would be because of the convenience layer JSONItem applies over the underlying Dictionary. But I doubt you’d notice it.

Use whichever you prefer.

1 Like