Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 11

Clever but Unwise: "role" XML attribute in RSG

Trying to read on RSG, i can't help but notice there are so many weird contraptions in Roku's xmlography that remind me the saying:
The difference between a clever man and a wise man is that

  • the clever man can extricate himself from difficult and intricate situations that

  • the wise man would never have gotten into in the first place

To wit, the just documented magic XML attribute "role", described understatedly as:
The Scene Graph node markup elements contained in the <children> element may include a special XML element attribute, role. The role attribute allows a node element to be defined as a child node of a parent node, and the child node to be assigned as the value of the parent node field identified by the role attribute value

Translation: because XML cannot have structured attribute values (only strings), let's flex shoving head between the legs. I found a good visual for the situation - it's yoga's Karnapid asana:
[spoiler=Karnapidasana:3pbguhi7][/spoiler:3pbguhi7] In fact t seems such a good fit, that i propose Karnapidasana for official logo of Roku Scene Graph! Check out the "interface fingers" - such a nice touch.

You'd think the Maker of RSG would have wisened up the first time they scribbled down something like:
translation = "[130, 160]"
rowItemSize = "[ [536, 308] ]"
Shiver me timbers, structures in strings surely give me pause. But apparently not to the Maker, who'd rather extricate himself with wickedly clever hacks from a corner where a wise man would have never painted himself in the first place. Roku's "SDK2.0" is full of valiant contortions in attempt to (a)dress the self-inflicted wounds of committing to XML for SG!

What's the alternative, you may ask? Using pure BrightScript for SG instead of XML comes to mind - B/S nested structures have none of the XML limitations - nor for that matter would you have to write your functions into <![CDATA[  ]]> text blobs nor exile them to different files (cue yoga uri-asana).

Couple of months ago I whipped a sample BrightScript syntax for SG in an afternoon - mind you, not the only approach but a reasonable one - and would have implemented and using it by now if the "BrightScript/XML Markup Equivalence" were complete - which it isn't. RSG remains belligerently hostile to BrightScript functions^ - they are not allowed as field types, get stripped on structure copy, can't pass them between threads nor re-assign them to events like init() and onKeyEvent()...

(^) even as functions in B/S are literals, completely lacking context/closures - the one true advantage, a blessing-in-disguise that BrightScript has here over all other scripting languages i know. In Python, Lua, Javascript, Ruby, you-name-it - functions drag with them lexical scope entrails, not so in B/S - Brightscript function's byte-code could cross unchanged (or even be shared) between different VM instances. B/S functions are immutable and context-free, so clean for the purpose of multithreading - it's beautiful! And RSG squanders that - why? Is it resentment by the "XML people" for the "BASIC people"?
0 Kudos