Roku Developer Program

[EnTerr]

I propose that "?." and "?[]" operators be added to BrSc to make developers' life easier. They are just like the "unquestionable" operators, except check first if invalid and if so, return said invalid instead of raising error. E.g.

foo = bar?.baz  ' bar.baz if bar is valid, otherwise invalid
foo = bar?[0]   ' bar[0] if bar is valid, else invalid

This is not something i invented, it is present in VB.net, for explanation and example see https://msdn.microsoft.com/en-us/librar ... cs-lang=vb
They call them "null-conditional operators" there, suppose could be "invalid-conditional dot" here (but i kind of like "questionable dot").

Another way of thinking of it, when having a chain of these like "a?.b?.c?.d?.e?.f" is "keep indexing by field till the end, unless you fail at some step; if you fail, return the last result in the chain". This would simplify life when working with roXML for example - instead of doing a ladder of "if"-s with separate handling of failures, to avoid exception - can type the whole expression and if the result is invalid, handle it all together.

And of course, the regular ("unquestionable") versions of the operators keep working as before by raising error on failure. Mixing is not a problem, subject to what we really wanted, e.g. in "a?.b.c?.d?.e.f" the ".c" will crash hard if lookup()/GetNamedElementsCi() are not applicable.

Anybody else in support of such operator?
If so, please reply with specific examples you know when this could be handy.

Scenographic example from me:

m.top.myCatalog[sect_id][prod_id].price

Maybe i should formulate this as a puzzle ... there is one specific "dot" above, that is extremely perilous and could fail at any time and unpredictably so, crashing the program. Which one is it, take a guess? 8-)
It would make sense being able to protect against that with "questionable operators"

PS. is "Doubting Dot(as)" a better name? "iffy index"? 🙂

[RokuKC]

That's certainly an interesting suggestion. Anyone else want to comment?

I think this is a common problem that developers face when working with complex XML or JSON hierarchies.

On the other hand, it would lend itself to misuse viz. "hiding" data or coding errors.

x = a?.b?.c?.d?.e?.f
if x = invalid
' hmm, what went wrong?
' maybe it is an expected case that the leaf value was not specified,
' or maybe I just made a typo in the path
' or maybe the server data format changed so that 'b' is now 'bs'
end if

Using a utility function to achieve the above access via a path spec lets you get the same functionality, but with the ability to add clear diagnostics at the same time.

[EnTerr]

"RokuKC" wrote:
I think this is a common problem that developers face when working with complex XML or JSON hierarchies.

Indeed it is - i can attest to that. E.g. my experience parsing ever-changing CraigsList. Another example would be the volatility of RokuCo's own web services, see viewtopic.php?f=34&t=95592 for discrepancies between documentation and reality

On the other hand, it would lend itself to misuse viz. "hiding" data or coding errors.

It might. Which is why the proposal is not to change "." to never err - but be able to explicitly ask for the behavior, having to type "twice as much". One wouldn't type that "by mistake", if they do - they meant the "questionable behavior".

x = a?.b?.c?.d?.e?.f
if x = invalid
' hmm, what went wrong?
' maybe it is an expected case that the leaf value was not specified,
' or maybe I just made a typo in the path
' or maybe the server data format changed so that 'b' is now 'bs'
... in any event, the channel DOES. NOT. CRASH. [E.T.]
end if

It gets to asking ourselves what happens in production?
I submit to you, that it is "sacrosanct" that an app in production "shalt not crash". They should be resilient. It would be better to show a befuddled "Some error happened. Don't do this. #XYZ" popup and recover the app flow or exit gracefully (whatever the `if` above pleases) - rather than having the channel close mysteriously.
I tend to refer to that as "The spice must flow"^ principle.

Can all 5 checks above be done with a "christmas tree" IFs^^ ? For sure, but let be realistic - (we) developers are lazy and would rather omit checking the unlikely scenarios - not to mention that each new branch would be a separate case to test (counter-Occam trouble).


(^) or i can give a Nazi spin to it as "arbeiten uber alles" (working above all else) or maybe Latin Labor omnia vincit (working conquers all). I hope is clear what i mean
(^^) how is this called by the way? I love the RokuMarkn's "you've got to tilt your head 45 degrees to read the code" - but is there established name for it? For some reason "christmas tree" comes to mind

[EnTerr]

But yes indeed 🙂 - what do other developers think?

[Komag]

It's way over my head :shock:

[belltown]

"Komag" wrote:
It's way over my head :shock:

It's on the top part of my head where the headaches happen. :shock:

Microsoft added null-conditional operators ( :?: ) and null-coalescing operators ( :?: :?: ) to C#, and I have played around with them a little. They don't really add any new functionality (not like, say, implementing multi-threading in BrightScript); rather, they just save typing (like adding support for pre- and post- increment/decrement operators).

I suppose if you type less code, then there may be a chance of introducing fewer bugs, and getting your code typed quicker, and there even may be cases where the code is more readable. However, my personal preference is to make code easier to document, debug, test and maintain. I find it easier to set a breakpoint in a long-hand conditional statement. I find it easier to keep track of what code I need to test, an if-then-else telling me more clearly that I have at least two different paths to test. I find (reading other people's code) that sometimes it's not clear what's going on with the ? and ??, unless the code is well-commented, in which case the extra time spent writing the explanatory comments could have been spent writing an if-then-else statement that didn't need any explanation.... but that's just me.

That's just my own opinion. I can see philosophical arguments both ways, and I don't really mind one way or the other if Roku implemented these features. Personally though, I think there are much more worthwhile things Roku engineers could be doing with their time -- fixing bugs, for example, or maybe even coming up with an actual bug reporting and tracking system (something Bugzilla-like, for instance), so developers (and Roku engineers) don't have to spend unnecessary time trying to track down and reproduce bugs that have already been reported, scouring random forum posts to see if someone has already found a solution, trying to decide when and how often to keep re-posting issues until someone takes note, not even knowing whether something you reported 3 years ago has even made it on to their list...

[EnTerr]

"belltown" wrote:

"Komag" wrote:
It's way over my head :shock:

It's on the top part of my head where the headaches happen. :shock: ...

Fair enough, into the junk drawer it goes.
I added a poll, in case unusual number of people vote for it (Vox Populi, Vox Dei), then maybe re-consider.

Personally though, I think there are much more worthwhile things Roku engineers could be doing with their time -- fixing bugs, for example, or maybe even coming up with an actual bug reporting and tracking system (something Bugzilla-like, for instance), so developers (and Roku engineers) don't have to spend unnecessary time trying to track down and reproduce bugs that have already been reported, scouring random forum posts to see if someone has already found a solution, trying to decide when and how often to keep re-posting issues until someone takes note, not even knowing whether something you reported 3 years ago has even made it on to their list...

How about if we start with a simpler goal - like a commitment to REPLY to each and every email^ sent to developer at roku.com... eventually ?
Then improve on that by putting a time frame - "within a week" is a good start, with "one business day" being a goal to strive to.
Then improve on that by adding tracking# to the cases that cannot be addressed satisfactory in a single response.

(^) Which is not obvious spam.

[RokuKC]

"EnTerr" wrote:

...
It gets to asking ourselves what happens in production?
I submit to you, that it is "sacrosanct" that an app in production "shalt not crash". They should be resilient. It would be better to show a befuddled "Some error happened. Don't do this. #XYZ" popup and recover the app flow or exit gracefully (whatever the `if` above pleases) - rather than having the channel close mysteriously.
...

Personally, I disagree completely. 🙂

I've seen way too much bad coding (C++/Java/C# pseudo example "catch (...) { // do nothing }") inflicted on customers.
Silent failures are worse UI-wise, customer support-wise and diagnostic-wise than having the application quit.
If the application does nothing when a button or action is selected, or showing an infinite spinner, or locks up, that is worse than having it quit, as it hides the diagnostic info from the developer + platform (*).

Showing "befuddled" error messages is almost as bad to the majority of customers (who are not techies and shouldn't be asked to do the job of testing/diagnostics).
"Opps: my code is screwed up #@$!: Please report error: runtime error 254"
(spelling error intentional; I've seen many real-world examples of such 'beautiful' UI... unfortunately customers tend not to appreciate them as much as the developer).

I've also seen plenty of examples where continuing after an error is dangerous, and results in corrupted user data.
This may be a lesser degree of issue in BrightScript apps compared to native execution environments, but I have seen a real-world example of it recently.

End rant. Again, this is just my personal opinion. 🙂

(*) Granted, application developers need diagnostic information from the field and the platform needs to support that. That's a topic for other conversations, but the lackings/limitations aren't an excuse for providing poor customer experience.

[EnTerr]

"RokuKC" wrote:
Personally, I disagree completely. 🙂

i beg to differ!
As in, "we agree much more than disagree". We agree on the desired outcome - smooth, reliable UX - but may differ on the way to get there.

I am about the "tools". E.g. should there be try-catch exception handling in languages or is it evil because of possible misuse? What's the alternative - expect the developer to always check the return code from fread()/fwrite()/fclose() ? That works only on paper - but try-catch works equally well on paper too. The person that writes try-catch-ignore is the same one that won't check the success/fail codes from fn calls - and there is nothing you can do to get them straight. Pointing out "catch (...) { // do nothing }" as example of the try-catch concept failure is like pointing cases of airbag broken noses/seatbelt cracked ribs. Yes, there will be lots of these - and there will also be whiplashes and maybe even fatalities - but overall/statistically we are way better off with people not flying through the windshild.

So, say on one end we have (A) people like @belltown or me, or you who (i presume) will try to cover all cases, regardless how. On the other end we have (C) the "irreparable" coders who'll do catch-all-do-nada^ and won't check status codes. And then we have a whole (B) gray area in the middle - people who might or might not do it; if it's easy, they will - if it's laborious, "fuhgeddaboudit!"

(C) are beyond saving, needn't bother. (A) know what they are doing - need not worry about them (although it's a plus if their life can be made easier). Group (B) is who i was thinking about, it's also by far the largest case.

Let's look at an example, the infamous "SThree" SG demo. It was produced in-house by the Co, so all "variables" are observable. Unplug the network and start the app - what happens? It hangs^^! Why is that? It is an open-end question, opportunity to muse over because you can literally walk to that person and ask them about the reason. Maybe i am being overly optimistic here but I theorize that they are in the "B" class above (i.e. redeemable) and would have done better if there were better/easier means for handling exceptional/out-of-band cases.


(^) or do upfront a blanket "ON ERROR RESUME NEXT" - a statement whose mere existence we both will agree is Dark Lord of the Sith Evil
(^^) more fun: if severing network later inside