fromJSON parses JSON in wrong way

[prnxdev]

Describe the bug
Today I noticed that fromJSON function doesn't work for JSON collections. It returns only first found object inside object or collection.

To reproduce
Two things:

Run inside MTA this:

outputDebugString(fromJSON('{"name": "Piorun", "position": { "x": 0, "y": 0, "z": 0 }}')) 
-- you will get { x: 0, y: 0, z: 0 } in debug console

and open web console (ie. Google Chrome DevTools) and use this code:

JSON.parse('{"name": "Piorun", "position": { "x": 0, "y": 0, "z": 0 }}');
// you will get object { name: 'Piorun', position: { x: 0, y: 0, z: 0 } }

Expected behaviour
Should return this:

{ name: 'Piorun', position: { x: 0, y: 0, z: 0 } }

Screenshots
none

Version
everything newest

Additional context
none

[Pirulax]

It's because MTA is retarded.
You need an extra array, that is:

outputDebugString(fromJSON('[{"name": "Piorun", "position": { "x": 0, "y": 0, "z": 0 }}]')) 

[prnxdev]

It's really misleading. Since collections are inside [...] brackets it shouldn't look like this because there still is problem with them. I have this JSON (it is MongoDB output) which I want to parse:

[
  {
    "_id":"5fe513b7132fc155b571d479",
    "modelId":567,
    "position":{
      "x":0,
      "y":0,
      "z":0
    },
    "rotation":{
      "x":0,
      "y":0,
      "z":0
    },
    "__v":0
  }
]

and it's not working properly (tbh it's not working at all)

[prnxdev]

Ok don't know why but it's working when I added [...] inside this collection. outputDebugString shown me something different that's why I was confused. IMHO adding [...] is stupid and should be changed but for now - it works and I cant move forward.

[Pirulax]

Not sure if changing it would break backwards compatibility. The issue has been discussed before, although not sure in which issue (that is which #). Perhaps we should automatically add the [...]. Somehow..

[Pirulax]

Ah, I see. Its done like this so that this works:

local name, weapon, ammo = fromJSON("[\"Desert Eagle\", 24, 147]")

[DREFTHUN]

Don't change it, please. It is working perfectly fine and all of my resources use this method and I really don't feel like rewriting every one of my resources just because one user isn't satisfied with it.

[prnxdev]

I think it should be added to 1.6 so it doesn't have to be backward compatible with 1.5.x

[DREFTHUN]

This function was working the same way as today since 2008. Do you really think backwards compatibility isn't important? Everyone will have to rewrite every one of their resources since 2008 that is using JSON, just because you don't like the way it is working. Don't be selfish.

[prnxdev]

I'm not selfish? I just know that if I have 1.x version of anything it doesn't have to be backward compatible with 1.y (where y < x). It's just natural way of creating programs or modules and having different version of it. I just want MTA team to change this behavior to be the same as everywhere in other languages. Someone who wants to use JSON and is not into "JSON's MTA world" for long time (like me, I never used JSON in MTA tbh) must know about few "things" and I think that many will say "damn, that's stupid, why I have to add special brackets for this?".

.. just because you don't like the way it is working.

For me - it's bug because It's not parsing JSON properly. JSON format with added square bracket's isn't proper JSON format

Lastly: good programmer would create some simple one function to add those brackets (like I do) so everything that should be change would be only one function.

[Pirulax]

MTA is very backwards compatible, like we still have MTA 1.0 functions "deprecated". Also, every value in the array will result in a separate variable, eg.:

local v1, v2 = fromJSON('["value1", "value2"]')
print(v1, v2) -- value1, value2

What we could do: Add an argument which indicates there's only one value (thus no extra array needed).

[DREFTHUN]

Also backwards compatible doesn't mean that something written in 1.6 should work in 1.5.8. It means that something written in 1.5.8 should work in 1.6, and in the case that you are saying, that wouldn't work. This function works, and the first thing you should've done was try toJSON with a table and see the outcome, then adapt to it. Not open a bug report.

[StrixG]

@pawel-miczka, your example is incorrect. It works as intended:

[prnxdev]

There's weird thing that happens to outputDebuString. It sometimes shows things in incorrect way. I will try to test fromJSON more since I am working on authorization system using external service (API). I will paste my results.

[DREFTHUN]

Use iprint.

[Pirulax]

It isn't parsing it in the wrong way, this is how fromJSON works.
A Lua function can return multiple values, and that's why the top level array is unpacked.
I agree it's not ideal. It's pretty easy to fix tho, a simple bUnpackTopLevelArray or similar flag can be added.