Scene graph components preserve cases

This has nothing to do with Scene Graph, it is how Associative Arrays work.  See the discussion under the dot operator in the Brightscript Language Reference which discusses it and explains how to create Associative Arrays with mixed-case keys.

--Mark

"RokuMarkn" wrote:
This has nothing to do with Scene Graph, it is how Associative Arrays work.  See the discussion under the dot operator in the Brightscript Language Reference which discusses it and explains how to create Associative Arrays with mixed-case keys.

Hmm, given that arr["kEy"] = "val" preserves the case, shouldn't that apply to string-literal keys in AA literal?

BrightScript Debugger> h = {}: h.LowerMyCase = 1: h["PreserveCase"] = 2: ? h
<Component: roAssociativeArray> =
{
    lowermycase:  1
    PreserveCase:  2
}

BrightScript Debugger> h = {LowerMyCase: 1, "PreserveCase": 2}: ? h
<Component: roAssociativeArray> =
{
    lowermycase:  1
    PreserveCase:  2    'desired result (simulated)
}

Intuitively it feels "right" that when specifying the key "quoted" like so in AA literal, the case should be preserved. I know, that all is syntactic sugar... but why not make it so? Seems like a convenience!

I dunno, I could argue either way.  Suppose someone writes this code

companies = {
  Roku : 100
  Google : 85
  Amazon : 90
  Hewlett-Packard : 55
}

Oops, the last line doesn't compile.  The developer realizes she just needs to put quotes around "Hewlett-Packard".  Then she spends days trying to debug a problem that only occurs with that entry, because she didn't realize that the caselessness changed just because she added the quotes that she was forced to add.  Bundling different semantics into a sometimes unavoidable feature seems likely to cause confusion.

--Mark

"RokuMarkn" wrote:
Suppose someone [...] spends days trying to debug a problem that only occurs with that entry, because she didn't realize that the caselessness changed just because she added the quotes that she was forced to add.  Bundling different semantics into a sometimes unavoidable feature seems likely to cause confusion.

Right. Let's weight the probabilities though. What kind of issue could case-less-ness cause? 
I am struggling to imagine such scenario because the item would still be findable in the AA. Yes, theoretically code can be written to fail but what's the practical likelihood - weighed against the benefits and thinking of quotes "Preserving the Case". It would have to be a perverse and contrived scenario, in which one insists on typing AA literal in mixed-case but insists on implicitly enumerating the keys in lower-case.

Now compare that to the intuition of an "innocent" developer who sees or writes (case in point, zy856n above):

myAA = {"firstKeyWatchMe": "1", "secondKeyWatchMe": "2"}

 and expects it to behave in a case-sensitive manner since it looks exactly like a JSON which, by and large, is case-sensitive^. And which choice is more likely to cause confusion - preserving-case or losing-case? ^^

Or a seasoned Roku developer, that knows arr["MiXaLot"] preserves case and has whatever obscure need to preserve key case in an AA literal - wouldn't they have natural hope that {"keyName": ...} preserves case too?

Yes, 100% of cases cannot be satisfied but that's with everything in life - and in this case seems to me when weighing-in, it would be 10:1 "for" vs "against" the quoted keys preserving the casing.

(^) i don't think that's in JSON spec but you know what i mean. Getting sidetracked, doesn't parseJSON() already preserve case? I think it does (can't check right now)
(^^) Worth noting, a "diligent" developer that always spells the keys the same way will not be affected at all by which way quoted-keys are treated