Roku Developer Program

[greubel]

I use it mainly for logging and debugging. It's a lot easier just to display the type than a large case statement to find out what it is.
Would be nice if it was documented along with isWhatype().
I looked through my code and there is only one instance where I check for a specific value but I could change that to the boolean check.

[RokuJoel]

"RokuMarkn" wrote:
Am I correct that GetType is only useful for debugging? There isn't an real purpose for GetType in production code, is there?

--Mark

Logging errors is also important in production code, so you can have feedback if a large part of your audience is experiencing playback errors. Not many channels do this, but there are a few. Would be nice to know what the values returned by gettype() mean though.

"greubel" wrote:
Would be nice if it was documented along with isWhatype().

Is that really a thing? I'm not able to execute either msg.iswhattype() or iswhattype(msg) for example, even if I spell it like you did.

- Joel

[greubel]

Is that really a thing?

No, the isWhatype() was to represent all the possible boolean "is" calls.

[EnTerr]

"RokuMarkn" wrote:
Am I correct that GetType is only useful for debugging? There isn't an real purpose for GetType in production code, is there?

Besides the need demonstrated by Greubel's case (to be able to reasonably log unknown/future events 3 hours into a run), well...
How about being able to use universal dispatcher:

' init phase
dispatcher = {
    roGridScreenEvent0: handle_isListItemSelected(m, msg), 
    roGridScreenEvent1: handle_isScreenClosed(m, msg), 
    roGridScreenEvent4: handle_isListItemFocused(m, msg), 
    roGridScreenEvent7: handle_isRemoteKeyPressed(m, msg), 
}
...
' inside msg loop, have ensured msg <> invalid
handler = dispatcher[type(msg) + msg.getType().toStr()]
if handler <> invalid:
    handler(m, msg)
end if

That'd be handy (i won't mention the P-word) in multi-sink port case instead of a long if-elsif chain, advanced coders may go for "inheritance" style - by copying the AA of generic dispatcher and then replacing handler functions as needed.

[RokuMarkn]

That's what I'm concerned about -- I don't think we should encourage using the type numbers in a switch in production code. The isXXX predicates isolate the code from those values, leaving us free to change them (unlikely) or make more complicated predicates (maybe two different events would return true for isSomething). Anyway, I don't object to documenting them, I just want the documentation to be clear on how the values should be used.

--Mark

[EnTerr]

"RokuMarkn" wrote:
That's what I'm concerned about -- I don't think we should encourage using the type numbers in a switch in production code. The isXXX predicates isolate the code from those values, leaving us free to change them (unlikely) or make more complicated predicates (maybe two different events would return true for isSomething). Anyway, I don't object to documenting them, I just want the documentation to be clear on how the values should be used.

I have to say, the more i think of it - the more i like the idea of "switch"-style event dispatching using this sort of "branch table" (after all, it's preferred way of doing it in languages w/o switch proper like Python and Perl). It gives expressive power - say i already have the main show event handling nailed down and want in addition to handle some "side show" like roUrlEvent (or roTextureRequestEvent, roFileSystemEvent, ...). Well if i have the utility handlers in my tool-belt, all i have to do to add that functionality is to say "dispatcher.append(urlEventHandler); dispatcher.append(devInfoEventHandler);" - and by adding the items from tool AAs to the dispatcher AA, all is done. Am i the only one getting excited about this, anyone else... anyone?

Mark - I understand and share your abundance of caution about "magic constants". But using such is already fact of life in BrightScript - many events (roUrlEvent, roUniversalControlEvent, roVideoPlayerEvent etc) come with tables of magic numbers. Also we have to check for magic strings, e.g. if type(msg) = "roUniversalControlEvent". Which gets annoying when something can come as either "String" or "roString" - or my gut tells me to capitalize it "roXmlList" (wrongly). The righteous way would have been to have isTypeRoUniversalControlEvent() predicate and so on.

And indeed it is highly unlikely that assigned numbers will change; documenting them in a table will help to keep them straight. Having compound/meta predicates is worth a thought - but does not prevent the use of "raw" numbers. E.g. ummm... (can't come with a good example)... say there were to be a isMediaEvent() that holds true if any of isPaused(), isResumed(), isFullResult(), isPartialResult(), isStreamStarted(), isRequestFailed(), isRequestSucceeded(), isRequestInterrupted(). But that does not change the fact that a specific type of event had happened and the branch table will still work.

To clarify, i don't advocate use of branch tables by everyone - isXXX predicates are clearly better for beginner programmers. With a dispatcher dictionary one needs to understand functions as object/values, about scope of variables and who "M" is... things that experienced developer would say "well duh". But if the ability is there, advanced coders can use it at their own risk.

[TheEndless]

"RokuMarkn" wrote:
Am I correct that GetType is only useful for debugging? There isn't an real purpose for GetType in production code, is there?

--Mark

While I won't say it's only useful for debugging, that is where I find myself using it the most. GetType() is the only way to find out what a specific event is during debugging. If there were a "getFriendlyName()" or something that returned what the isXXXX() name is it'd be a non-issue, but right now getType() is the only unique identifier for an event. Without it being documented, it's virtually impossible to figure out what event is in the queue. Likewise, there are a number of isXXXX() events that fire for various components that are not documented for those components (for example, roVideoPlayer and isListItemSelected(), isRequestSucceeded, and isRequestInterrupted().. or roImageCanvas and isButtonPressed().. or roListScreen and isRemoteKeyPressed()), but are for others, so getType() can be used to figure them out.