This is a kind of reverse logic (probably of "volcanic" origin).
In any case, my logical thinking does not work like that. I compare a term with a value and not vice versa. However, it is a mathematical equation in the end. Even more so with a test for an absolute value it becomes more strange.
But every now and then I have stumbled across the IDE pointing this out to me.
This is a kind of reverse logic (probably of "volcanic" origin).
In any case, my logical thinking does not work like that. I compare a term with a value and not vice versa. However, it is a mathematical equation in the end. Even more so with a test for an absolute value it becomes more strange.
But every now and then I have stumbled across the IDE pointing this out to me.
It is probably like a RPN calculator. Takes some time to get used to it vs a traditional calculator. I use to own a HP41CX calculator but lost it when they broke into my car when I stopped at a shop on my way home from work and me being inside the shop (it is just how SA is). Now I have a HP41 app on my cell. So used to using RPN over the last 40 odd years that I battle to use a standard calculator.
Some clarifications:
The compiler uses the left hand side value to determine the comparison type. In this case the compiler cannot know the type and therefore the type must match exactly.
Example:
B4X:
Dim d As Double = 0
Dim map As Map = CreateMap("test": d)
Log(map.Get("test") = 0) 'false
Log(0 = map.Get("test")) 'true
Log(map.Get("test").As(Int) = 0) 'true
This was always the behavior. The warning is relatively new.
I have had a hard time adjusting as well, but read Erel's post. It makes sense and I am glad the warning is there. I have had errors when the number was returned as a string and hence - no match. Not so with the number first.