Forum Discussion

dan_shneider's avatar
9 years ago

FormatJson results in a lower case string

I have a json like:
bodyJson = {
        "userUUID" : mUserUUID,
    }  
str = FormatJson(bodyJson, 1)
This str is sent as the string on AsyncPostFromString, with the following headers :
mRequest.AddHeader("Content-Type", "application/json")
mRequest.AddHeader("Accept", "application/json")
mRequest.AsyncPostFromString(str)
mRequest.EnableEncodings(true)

For some reason, the string str is all in lowercase ("userUUID" becomes "useruuid")
Any idea?

9 Replies

  • RokuKC's avatar
    RokuKC
    Roku Employee
    "dan_shneider" wrote:
    I have a json like:
    bodyJson = {
            "userUUID" : mUserUUID,
        }  
    ...

    For some reason, the string str is all in lowercase ("userUUID" becomes "useruuid")


    Associative array keys are case-insensitive by default, and in the case of associative array literal values and dot operator assignments are not case-preserving.
    Thus, if you do "print bodyJson" you will see that the assigned key name is "useruuid".

    Depending on your requirements, you could alternatively do:

    bodyJson = {}
    bodyJson["userUUID"] = mUserUUID


    and then the FormatJSON result would be what you expect, as the assignment using the literal is case-preserving on the key.
  • "RokuKC" wrote:
    Associative array keys are case-insensitive by default, and in the case of associative array literal values and dot operator assignments are not case-preserving.

    It would be better (better design) if string-literals as keys in AA literals are case-preserving, unlike the var-name keys. I.e.
    Brightscript Debugger> ? {"A": "A", B: "B"}   
    <Component: roAssociativeArray> =
    {
       A: "A"    'wishful thinking'
       b: "B"
    }

    It will both bring it in line with ["A"] behavior and also cater to developer's intuition of "no, i want it exactly as i wrote it - see, quoted verbatim! - no improvisations"
  • bodyJson = {}
    bodyJson["userUUID"] = mUserUUID


    This is working. thanks a lot.
  • Got bit by the same issue and took a while debugging it since server kept of rejecting the json request as FormatJson() gave a json with keys converted to all lower-case. Any future plans of making the keys case-sensitive for the roassociativeArray?
  • Doubt it, the whole language is case insensitive, except when it's not.  :cry:
    Personally I try to keep everything in my code lowercase_with_underscores instead of camelCase, just to enforce some consistency. The official Roku examples are all over the map in terms of camelCase, I was really confused at first until I found a mention in the docs that BS is case insensitive. 
  • I would as well, but the server folks are inconsistency using camel case in some places, all lower case in others and separated by _ in still others. I don't have control and the api's are already complete and being used. Changes now would wreck havoc in a bunch of other places.
  • Ok, so have a close, attentive look to this example:
    Brightscript Debugger> check = function(d): d.a = "a": d.A = "A": d["b"] = "b": d["B"] = "B": ? d: end function
    Brightscript Debugger> d = {}: check(d)
    <Component: roAssociativeArray> =
    {
       a: "A"
       B: "B"
    }
    Brightscript Debugger> d.SetModeCaseSensitive(): check(d)
    <Component: roAssociativeArray> =
    {
       B: "B"
       a: "A"
       b: "b"
    }


    The dot-notation is a case-lowering option.
    The [] indexing is case-preserving BUT case-insensitive at the same time - so use that if you are sure there will be no keys that differ only in upper/lower casing. And if you set SetModeCaseSensitive(), then the indexing operator turns into both case-preserving AND case-sensitive.

    That does not apply to the dictionary literals (i.e. `{a: 1, A: 2}`) though - they are allways case-clobbering (for now?)
  • Thank you for the clear explanation. It is good to know that there is a solution for same keys with different case if it ever comes up.