Array in an array

[madscijr]

I think you might have missed me mentioning SQLite, which resides locally. Not as a networked database. And would actually be easier than trying to implement JSON, which is designed for object-oriented programming. Since all you need is a two dimension array, SQL is much easier. Also, the functions for SQL handle the data gathering for you. Tell me which is easier: Looping through a file yourself and trying to parse data with hand-written functions or using something that is used by many successful software products and when you want data, you just ask for it with very simple language and suddenly it's in your array.
Do
If....
If....
If....
If....
Loop Until....

OR

"SELECT * FROM myTable WHERE myColumn = 'myValue'"
For X = Lbound(DB_Results) to Ubound(DB_Results)
do something
do something else
Next

I really do not think you see how difficult managing JSON with QB64 will be. Sure, some poor soul might write up some 10,000 line library from scratch for doing it but the user experience will be absolute garbage. I've managed to use a bit of a JSON library in QB64 before but it was just a crappy experience and made me regret wasting the time on it.

The way you're describing working with JSON sounds a lot like my experiences with XML, and that user experience IS garbage. My experience with JSON objects was entirely different. To illustrate I'd need to sit down at the computer & write pseudocode for a proper example, but forget the If If loop until. That DOES suck! What I am talking about is more something like: 

Vacuum(MyHouse.Bedroom.Floor)
SearchRoom(MyHouse.Bedroom)
For pCount = lbound(Planets) to ubound(Planets)
    ThisPlanet = Planets(pCount)
    For pMoon = lbound(ThisPlanet.Moons) to ubound(ThisPlanet.Moons)
        ThisMoon = ThisPlanet.Moons(pMoon)
         If ThisMoon.Radius > MinSize and ThisMoon.Bases.Count < MaxBases Then blah blah

That's a lame example, but the point is that you aren't looping like in XML to find the property you're looking for, because you just use dot notation to directly access those properties. The programmer isn't "managing JSON" - that's done by a JSONify (deserialization) function one time, when you load it into memory. In fact, you don't even use JSON unless you're loading/saving persisted values. Different use case.

Hey, I don't need convincing on the value of SQL - in another life, I wrote T-SQL & PL/SQL sprocs every day as a part of my job, and I was quite fond of it. I just don't see SQL and JavaScript objects as competition for one another. JSON has its uses - including interoperability with REST services. How are you going to work with an object some http service sent back using SQL? Totally different tools for different jobs, with some overlap.

For me one issue with relying on SQLite is reliance on a 2nd product. Now the developer and their user have to download, install and set up a 2nd tool, so you might not be managing JSON (which needs no managing to begin with) but you're now managing a dependency, and moving away from the "one and done" simplicity that makes QB64/PE such a pleasure to use. 

But I don't want to poop all over SQL, it does have its merits and strengths. I'm just more of a mind to say why not both, and use whichever one fits the need? JSON type objects and relational databases each have their own strengths and uses. 

Let me back up a second though - you found a JSON library for QB64? Do tell!