>>>>Here is my sample Json-formated string:
>>>>
>>>>

>>>>cJsonStr = [{"access_token":"OCu_7Rt","token_type":"bearer","expires_in":1209599,
>>>> ".issued":"Fri, 23 Dec 2016 21:58:29GMT",".expires":"Fri, 06 Jan 2017 21:58:29 GMT",
>>>> "issued":"Fri, 23 Dec 2016 21:58:29GMT","expires":"Fri, 06 Jan 2017 21:58:29 GMT"}]
>>>>

>>>
>>>I would worry about ".expires" and ".issued" as identifiers. Too lazy to look up if specific rules for JSON "key" naming exists, but starting with a period could create invalid property names if using eval() on JSON as some languages allow. OTOH: If you view the JSON just as a serialization of a hashmap, starting the hashmaps key with a period might not be forbidden, similar to vfp not allowing field names starting with a period, but a search field, which is indexed, can start with it.
>>
>>I believe the library takes care of that, since it serializes the JSON keys as properties of an VFP Empty object. EVAL() them is safe, afterwards.
>
>See slightly altered example of possible lookup-table / hashmap entries hard to consolidate on 1 object even when massaging property names ;-)
>I was talking about loJson = eval(lcJSON) available in JS and Python at least

I think if the resulting translated name matches one already in scope, it arrays them... I would have to look into the code again, but at least in the case of the nf* serializers I believe that's how this potential clash is handled.