[Library] cJson.ahk (version 0.4.1 pre-release)

[oldbrother]

Love this lib! Hi geek, are you going to develop one for V2?

[geek]

Love this lib! Hi geek, are you going to develop one for V2?

Maybe eventually, but I haven't had a lot of time for development lately. Before I can port this to V2, I must port the machine code library. Then I need to learn a lot more about how V2 objects work. In principle, I should be able to re-use most of the code, as I wrote it to treat ahk objects as generic COM objects in most cases.

However, I need to see how the COM interface interacts with Map objects given that Maps are the new key:value prototype instead of plain objects. Before, there was no separation of properties and "items" on an object, so I would just use the com property access interfaces. Now, I think I'll likely need to call Map's get/set methods to get at the items.

Using those methods may actually make some of my bandaid code unnecessary, such as dealing with big numbers used as keys. The COM interface for that does weird things, but as parameters to a method call it might "just work".

Does anyone know if Yunit has a functional V2 version?

[Xeo786]

Love this lib! Hi geek, are you going to develop one for V2?

Maybe eventually, but I haven't had a lot of time for development lately. Before I can port this to V2, I must port the machine code library. Then I need to learn a lot more about how V2 objects work. In principle, I should be able to re-use most of the code, as I wrote it to treat ahk objects as generic COM objects in most cases.

However, I need to see how the COM interface interacts with Map objects given that Maps are the new key:value prototype instead of plain objects. Before, there was no separation of properties and "items" on an object, so I would just use the com property access interfaces. Now, I think I'll likely need to call Map's get/set methods to get at the items.

Using those methods may actually make some of my bandaid code unnecessary, such as dealing with big numbers used as keys. The COM interface for that does weird things, but as parameters to a method call it might "just work".

Does anyone know if Yunit has a functional V2 version?

is this one you are looking for ? Yunit v2 branch

[TheArkive]

@oldbrother

Dont forget about this lib by thyqby. This is super fast JSON for v2.

[oldbrother]

Thank you TheArkive. Personally I like geek's lib with M-Code, and no external dll file. I'm using geek's 0.41 load big files. It's very fast, and I didn't encounter any errors.

[lexikos]

However, I need to see how the COM interface interacts with Map objects given that Maps are the new key:value prototype instead of plain objects. Before, there was no separation of properties and "items" on an object, so I would just use the com property access interfaces. Now, I think I'll likely need to call Map's get/set methods to get at the items.

I'd guess that you were using GetIDsOfNames to get the ID corresponding to a key and then Invoke to set or get the value. You can instead just call Invoke with DISPID_VALUE for the ID, DISPATCH_PROPERTYPUT or DISPATCH_PROPERTYGET for the flags, and the key as a parameter. Actually, I think that would work in both versions, effectively being the same as x[y] (which implies some differences in behaviour between the two versions). However, the translation of DISPID_VALUE to x[y] is only one-way in v1.

Using those methods may actually make some of my bandaid code unnecessary, such as dealing with big numbers used as keys. The COM interface for that does weird things, but as parameters to a method call it might "just work".

There are documented limitations with regard to numeric strings and pure numbers as keys, but that has nothing to do with the COM interface.

Any weird things that the COM interface will do to big numbers, it will do to parameters in a method call. There isn't really any other way to pass a number, except to convert it to a string and then to a property ID with GetIDsOfNames, to be converted back to a string when the object is invoked; and that wouldn't cause any particular weirdness.

For parameter values received via IDispatch::Invoke, unlike v2, v1 does not explicitly support VT_I8. Unsupported variant types are coerced to string via VariantChangeType.

[ananthuthilakan]

this is conflicting with google translate library