Roku Developer Program

[ksjun]

Comparing "roMessagePort" object always throws "Type Mismatch Error".

print CreateObject("roMessagePort") <> CreateObject("roMessagePort")
Type Mismatch. (runtime error &h18)

port1 = CreateObject("roMessagePort")
port2 = CreateObject("roMessagePort")
If port1 <> port2 Then
End If

How can I compare these?

[RokuJoel]

Well, that is pretty strange. You can do this though:

?type(port1)=type(port2)

or

if type(port1)="roMessagePort" and type(p2)="roMessagePort" then
     print "Both are message ports"
else if type(port1)="roMessagePort and type(p2) <> "roMessagePort" then
     print "Only Port1 is a message port"
else 
     print "Only Port2 is a message port".
end if

That will let you know for sure if both are actually message ports, if that is what you are trying to determine.

- Joel

[EnTerr]

I think @ksjun is trying to do exactly what they said: compare 2 port objects to see if they are identical - checking if both are ports makes no sense.
I am away from Roku players so can't check to see the exact error but if it throws "type mismatch" error, that is a clear bug that should be logged (to fix or not is another story).

It is reasonable expectation from all languages (i can think of) that objects of the same type should be at least comparable for identity, if not equality. In other words this should never err:

if type(o1) = type(o2) then
    ? (o1 = o2)
endif

[TheEndless]

"EnTerr" wrote:
I am away from Roku players so can't check to see the exact error but if it throws "type mismatch" error, that is a clear bug that should be logged (to fix or not is another story).

With very few exceptions, none of the Roku roXXX components can be compared by reference. Definitely a shortcoming, and a pain in the neck, but I don't know if they'd classify it as a bug.

[EnTerr]

"TheEndless" wrote:
With very few exceptions, none of the Roku roXXX components can be compared by reference. Definitely a shortcoming, and a pain in the neck, but I don't know if they'd classify it as a bug.

I had no idea non-comparability was that pervasive. Yes, that's not simply a bug but an omission in the language of a... well, moderate size. Either way should be considered for correction. Implementation-wise "=" checking for identity (reference equality) will be easy, question is persuading the language architect it is a good thing.

You said "with a very few exceptions" - do you know of any at all?
Quick check and now it seems logical to me that all "object" types do not compare - starting with arrays [], dictionaries {} and going through all ro* intrinsics. In addition functions and interfaces, they don't compare either. The rest (numbers, strings, booleans) compare - and invalid is very interesting case, being pansexual - it "=" mates with everything.

[TheEndless]

"EnTerr" wrote:

"TheEndless" wrote:
With very few exceptions, none of the Roku roXXX components can be compared by reference. Definitely a shortcoming, and a pain in the neck, but I don't know if they'd classify it as a bug.

I had no idea non-comparability was that pervasive. Yes, that's not simply a bug but an omission in the language of a... well, moderate size. Either way should be considered for correction. Implementation-wise "=" checking for identity (reference equality) will be easy, question is persuading the language architect it is a good thing.

You said "with a very few exceptions" - do you know of any at all?
Quick check and now it seems logical to me that all "object" types do not compare - starting with arrays [], dictionaries {} and going through all ro* intrinsics. In addition functions and interfaces, they don't compare either. The rest (numbers, strings, booleans) compare - and invalid is very interesting case, being pansexual - it "=" mates with everything.

You can compare two roFunction references for equality (which is handy for pseudo-inheritance overrides/overloads).

[EnTerr]

"TheEndless" wrote:

"EnTerr" wrote:
You said "with a very few exceptions" - do you know of any at all?

You can compare two roFunction references for equality (which is handy for pseudo-inheritance overrides/overloads).

Oh gee, you are right. Kudos to you, sir!
Funny, i tried that yesterday and i can swear it gave me an error... but no, you are right. I wonder what i goofed up.

RokuJoel, would you please file enhancement request to make all types comparable in the same way?
(Sorry for calling by name, just want to point out this is specific call for action and not a random chat; trying to work on my [lack of] communication skills).