during debugging, I just came across a quite strange behavior of operator precedence with integers and booleans. Please have a look to the following code detailing my findings:
[code] dim v as Variant
v = 3
system.DebugLog "v = " + str(v) //prints 3
system.DebugLog "v.type = " + str(v.Type) //prints 2
System.DebugLog "variant.typeobject = " + str(Variant.TypeObject) //prints 9
if not v.Type = Variant.TypeObject then
Break //breaks here - that’s not expected at the first glance…
if v.Type <> Variant.TypeObject then
Break //breaks here. ok that works, but shouldn’t this be equivalent?
if not (v.Type = Variant.TypeObject) then
Break //breaks here, that’s ok, again
if (not v.Type) = Variant.TypeObject then
Break //breaks here. as in first test. so it seems it is doing that instead.
//obviously the not has a higher precedence then the =, which is fine for booleans
//but variant.type is an integer, can that be negated?
dim i as integer
dim b as Boolean
'b = not i //no, that won’t compile…
//maybe that’s because Variant.Type is a Method, try this:
'b = not func() //not, won’t compile either…
system.DebugLog "not(v.type) = " + str(not(v.Type)) //prints -3 //very stange, would expect -2 at best.
//this explains why the original if-statement is behaveing as it is,
//but still - why can I invert this expression v.type at all?
Can anybody explain what is happening here? any implicit type conversion or operator_convert I’m not aware of?