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.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Komag
Roku Guru

Re: Checking Type() is case sensitive - undocumented?

My usage is just to check that it's a string and not a boolean, or that it's a boolean and not an array nor an integer, etc, just basic distinctions.
0 Kudos
RokuMarkn
Visitor

Re: Checking Type() is case sensitive - undocumented?

I'd tentatively suggest the code should be redesigned if you need to check things like that. Perhaps there's a good use case for keeping different types in the same variable but offhand I can't think of one. I certainly have never had the need to check types at run time, except to distinguish messages returned from Wait().

--Mark
0 Kudos
EnTerr
Roku Guru

Re: Checking Type() is case sensitive - undocumented?

"RokuMarkn" wrote:
I'd tentatively suggest the code should be redesigned if you need to check things like that. Perhaps there's a good use case for keeping different types in the same variable but offhand I can't think of one. I certainly have never had the need to check types at run time, except to distinguish messages returned from Wait().

Off the top of my head example: last year i wrote a XML/XHTML parser (because at the time roXML could not parse nor even hold the result of parsing things i was facing, like e.g. "<a> b <c/> d </a>" - and it still cannot do either on fw3). And i needed that there, since when doing recursive walk of the tree, i could either get an array/list, a dictionary or a string (leaf) and had to act accordingly.

PS. NVM - this viewtopic.php?f=34&t=67294 is probably a better/simpler example, a function that when given "something" externalizes it to JSON
0 Kudos
RokuMarkn
Visitor

Re: Checking Type() is case sensitive - undocumented?

Ok, those are both reasonable examples. Both are related to serialization.

--Mark
0 Kudos
Komag
Roku Guru

Re: Checking Type() is case sensitive - undocumented?

"RokuMarkn" wrote:
I'd tentatively suggest the code should be redesigned if you need to check things like that. Perhaps there's a good use case for keeping different types in the same variable but offhand I can't think of one. I certainly have never had the need to check types at run time, except to distinguish messages returned from Wait().

--Mark


You are likely right, I'm still a programming beginner and haven't the experience to really know all my "best practices". I may be able to rework some things to avoid some or all of these Type checks.

But I dunno, they're awfully handy at times. Sometimes I'll have multiple things that will call the same Function, but depending on what it is, one thing sends a certain variable (as dynamic) as a Boolean and the other sends it as a String, and that Function handles the variable differently depending on the Type.
0 Kudos
TheEndless
Channel Surfer

Re: Checking Type() is case sensitive - undocumented?

"EnTerr" wrote:
Mmmm, good point.
I see roPath does ifString but who does ifInt (but roInt)?

As I mentioned earlier in this thread, there's at least one roXXXXEvent type that implements ifInt.

"EnTerr" wrote:
Personally per my Python exposure i am fan of "duck typing" ("if it walks like a duck and swims like a duck and quacks like a duck, i call that [type] a duck"). In other words if the type can perform the duties of a String, for all practical purposes it is a string. Which i can probably check if the value can/has ifStringOps, to be more precise.

I have some serialization methods that don't trust "duck typing" for obvious reasons. I also have some casting/conversion functions that need to know the real type.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
EnTerr
Roku Guru

Re: Checking Type() is case sensitive - undocumented?

"TheEndless" wrote:
As I mentioned earlier in this thread, there's at least one roXXXXEvent type that implements ifInt.

If by any chance you ever recollect (or re-encounter) which one, pls let me know - i am most interested to explore it

I have some serialization methods that don't trust "duck typing" for obvious reasons. I also have some casting/conversion functions that need to know the real type.

Huh. That's actually very un-obvious to me. Can you give me some examples, practical things that caused your mistrust?

Maybe you were afraid that checking with getInterface() coerces between Boolean, Int, Float and Double?! It doesn't, here is a cross-product test:
vals = [false, 0, 0.0, 0d] 
ifcs = ["ifBoolean", "ifInt", "ifFloat", "ifDouble"]
for each val in vals: for each ifc in ifcs: ? type(val,3), ifc, getInterface(val, ifc): next: next
0 Kudos
Komag
Roku Guru

Re: Checking Type() is case sensitive - undocumented?

Is your code spaced out like this? I don't recognize the "next"s - they replace END FOR? Are they more useful in some way, such as helping with some version of EXIT FOR or other option?
	vals = [false, 0, 0.0, 0d] 
ifcs = ["ifBoolean", "ifInt", "ifFloat", "ifDouble"]
FOR EACH val IN vals
FOR EACH ifc IN ifcs
? type(val,3), ifc, getInterface(val, ifc)
NEXT
NEXT
0 Kudos
TheEndless
Channel Surfer

Re: Checking Type() is case sensitive - undocumented?

"EnTerr" wrote:
"TheEndless" wrote:
As I mentioned earlier in this thread, there's at least one roXXXXEvent type that implements ifInt.

If by any chance you ever recollect (or re-encounter) which one, pls let me know - i am most interested to explore it

Looks like it's the roUniversalControlEvent.

"EnTerr" wrote:
I have some serialization methods that don't trust "duck typing" for obvious reasons. I also have some casting/conversion functions that need to know the real type.

Huh. That's actually very un-obvious to me. Can you give me some examples, practical things that caused your mistrust?

You're misinterpreting my use of "trust". It's not that I don't trust that something with the roInt interface will behave as an integer. It's that, if I'm serializing the data for error reporting, for example, I want to serialize the entire object, not just the roInt or roString values.

"Komag" wrote:
I don't recognize the "next"s - they replace END FOR? Are they more useful in some way, such as helping with some version of EXIT FOR or other option?

NEXT is identical to END FOR. NEXT is what VBScript/Visual Basic/Basic uses, so it's available as a convenience.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
EnTerr
Roku Guru

Re: Checking Type() is case sensitive - undocumented?

"Komag" wrote:
Is your code spaced out like this? I don't recognize the "next"s - they replace END FOR? Are they more useful in some way, such as helping with some version of EXIT FOR or other option?

No, i actually tested, then copyied that from the debug console - there one has to type all loops on the same line. This way you can just paste these 3 lines in console and see the result.

Otherwise i would have done it like you showed (sans capitalization of the keywords). next is exactly the same as end for. Traditionally in BASICs, for's are closed with next, B/S has in addition the "end X" variants. When i type in editor, i use end for... but i have no strong feeling one way or the other.
0 Kudos
Need Assistance?
Welcome to the Roku Community! Feel free to search our Community for answers or post your question to get help.

Become a Roku Streaming Expert!

Share your expertise, help fellow streamers, and unlock exclusive rewards as part of the Roku Community. Learn more.