Roku Developer Program

[EnTerr]

"TheEndless" wrote:

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

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

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

[TheEndless]

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

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

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