Forum Discussion

Komag's avatar
Komag
Roku Guru
11 years ago

Checking Type() is case sensitive - undocumented?

I've noticed that when I check the Type of a variable, it's case sensitive (at least for String/roString). Example:

IF Type(id) = "String" OR Type(id) = "roString" ' Could be either one, depending on custom id or not. ' Otherwise id must be a dummy temp blocker while a diff Mon is moving toward sq
	moveMon(TRUE, sy.mr[id], y, x, y2, x2, r2, rm, aa, sy, mAA, cAA) ' Sends tele as TRUE, Mon as sy.mr[id]
ELSE ? "moveAllMon(): At y" y ", x" x ", rm" rm ", trying to be moved: " Type(id) ' It's unlikely a teleCheck() occurs for sq Mon is stepping to, but could happen if tele just turned on
END IF


If I don't capitalize the S in String and roString, it will miss it and think it doesn't match!

I haven't noticed whether this is also true for Integer/roInteger, Array, etc
Roku Developer Program

33 Replies

Show More
  • TheEndless's avatar
    TheEndless
    Roku Guru
    11 years ago
    "EnTerr" wrote:
    Certainly if you are debug dumping roPath or roUniversalEvent, printing their true type() is desirable. But what else can you externalize from them, when saying "I want to serialize the entire object, not just roInt or roString"?

    I'm not sure if you're being so literal just to mess with me, or if you're truly confused by this. I have checks for Type(), because I want to know the object, not what interfaces it may implement. When dealing with intrinsics, checking for the interface is fine, but when working with objects, it's not always a simple as that. If you're just wanting to be type-safe, then checking for the interface is all you need to do, but that's not the only situation you'd ever want to check the type of an object. Let's say, for example, in 7.0 Roku decided to add the ifInt interface to an roDateTime object, so it could be natively treated like a timestamp. Without checking the type, my serialization code would have to be sure to check for an roDateTime before it checked for an ifInt, otherwise it would serialize the data incorrectly. If I have a Type() check in there as well, then a change like that wouldn't be an issue.
  • EnTerr's avatar
    EnTerr
    Roku Guru
    11 years ago
    "TheEndless" wrote:
    I'm not sure if you're being so literal just to mess with me, or if you're truly confused by this. ...

    I was genuinely asking and trying to understand. You said "obvious reasons" and i could not imagine what you meant. People think differently. I was looking very pragmatically on the matter at hand. Now i understand you were not about the existing situation but trying to future-proof your code. If the hypothetical example you just described happens - yes, certainly checking for type by name is more stable. I wonder if that need is limited to the general vicinity of "serialization", as Mark termed it.
  • TheEndless's avatar
    TheEndless
    Roku Guru
    11 years ago
    "EnTerr" wrote:
    "TheEndless" wrote:
    I'm not sure if you're being so literal just to mess with me, or if you're truly confused by this. ...

    I was genuinely asking and trying to understand. You said "obvious reasons" and i could not imagine what you meant. People think differently. I was looking very pragmatically on the matter at hand. Now i understand you were not about the existing situation but trying to future-proof your code. If the hypothetical example you just described happens - yes, certainly checking for type by name is more stable. I wonder if that need is limited to the general vicinity of "serialization", as Mark termed it.

    Not just for future proofing, but also to account for any other objects that might implement the interfaces that I don't know about.