Roku Developer Program

[Komag]

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.

[RokuMarkn]

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

[EnTerr]

"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

[RokuMarkn]

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

--Mark

[Komag]

"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.

[TheEndless]

"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.

[EnTerr]

"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

[Komag]

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

[TheEndless]

"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.

[EnTerr]

"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.