NOT bug or not?

General
1

Here is a piece of code that makes me think to a Xojo bug:

if not Listbox1.CellType(0,0) = Listbox.TypeCheckbox then msgbox "is NOT a checkBox" else msgBox "IS a checkBox" end if

The above code tells me a listbox cell IS a checkbox, while it’s not.
OK, I know this can be better tested with if Listbox1.CellType(0,0) <> Listbox.TypeCheckbox and I know that the NOT operator has an higher precedence over the = operator.

But here, seems Xojo is first negating the Listbox1.CellType(0,0) and then comparing with Listbox.TypeCheckbox.
This would be fine, stated that NOT has an higher precedence, but still not possible, since the Listbox.CellType method returns an integer.
Indeed, writing

if not Listbox1.CellType(0,0) then

I get a Type Mismatch Error.

So in the end, while the first code compile with no errors?

Is this a bug or I’m overlooking something?

2

I don’t know. Maybe try:

if not (Listbox1.CellType(0,0) = Listbox.TypeCheckbox) then

Haven’t tried it though

3

I think this is whats happening

[code] dim i As integer = not 3

//i = -3[/code]

you can ‘not’ an integer to negate it !?

4

oops, my eyes are too old. i = -4. No idea whats happening then.

5

[quote=62366:@Dirk Cleenwerck]I don’t know. Maybe try:

if not (Listbox1.CellType(0,0) = Listbox.TypeCheckbox) then
[/quote]

Yes this works and makes sense.
But in the my case I expect a compilation error.

6

[quote=62368:@Will Shank]I think this is whats happening

[code] dim i As integer = not 3

//i = -3[/code]

you can ‘not’ an integer to negate it !?[/quote]

I believe this is an undefined behavior.
Not 3 means everything which is not 3, so even 1234567 is valid.

7

NOT inverts the number bitwise, and doesn’t imply everything which is not 3. NOT 3 equals one specific number in the set of integer numbers.

For example, if we had to look at the bit representation then:

3 = 00000011

and

not 3 = 11111100

8

I think the way Xojo implemented it is technically correct. To get everything that is not 3 the “<>” is best used:

if MyNumber <> 3 then
  MsgBox "Xojo is awesome."
end if
9

The implementation is probably correct, you are right, but then why my code didn’t produce compilation errors. That’s the bug, I think.

10

The if statement can be reduced as:

if not Listbox1.CellType(0,0) = Listbox.TypeCheckbox then

is the same as

if not intA = intB then

is the same as

if intC = intB then

where intC = not intA. This is a valid statement hence why the compiler probably didn’t give an error.

11

[quote=62378:@Alwyn Bester]The if statement can be reduced as:

if not Listbox1.CellType(0,0) = Listbox.TypeCheckbox then

is the same as

if not intA = intB then

is the same as

if intC = intB then

where intC = not intA. This is a valid statement hence why the compiler probably didn’t give an error.[/quote]

This seems a good explanation.
Now I think the double meaning of the NOT operator is where the confusion starts.

12

The OP example is applying a BITSWISE “NOT”, while the example with the statement in Parends is executing a proper LOGICAL NOT, they are quite different and as observed produced very different results, but both for a proper reason.

13

[quote=62363:@Massimo Valle] I know that the NOT operator has an higher precedence over the = operator.
[/quote]
Apparently you overlooked this thing you know
Since NOT has higher precedence you HAVE to use () to force the evaluation to be what you intend

if not ( Listbox1.CellType(0,0) = Listbox.TypeCheckbox ) then msgbox "is NOT a checkBox"

NOT a bug - but certainly a confusing thing if you’re not aware of the dual nature of NOT

14

Exactly, and that’s why I believe the logical and arithmetic negations should have a different notation.

15

I’d tend to agree, but the ship has sailed.

16

We’d break a LOT of code if we did that today

17

When I did VB I liked the dual nature of AND and OR and (less often) NOT. When I went to REAL that wasn’t available so I got used to the BitwiseAnd etc. methods. Now, given the opportunity to go back, I won’t. Now, I won’t even come close to putting AND/OR/NOT even close to non-boolean things. And I never use NOT if I can help it, I just rewrite it check the TRUE, not the FALSE.

I also learned the same lesson with operator precedence. Given the good advice of “don’t bother to remember” (Code Complete, Steve McConnell) I use parentheses completely - no compound statements ever.

After years of trying to understand code I wrote long ago, I insist I write things in a self documenting manner - never be assumptive, ALWAYS be explicit.

18

when in doubt bracket :stuck_out_tongue:

19

Isn’t ambiguity a wonderful thing? A long time ago a programming teacher told me that Murphy’s Law applies to coding. Essentially, if a line of code CAN be misinterpreted, it WILL be misinterpreted. He stressed the idea, as Norman said, use bracketing to make sure the code will do what you think you want it to do.

20

I completely agree on this. I always put bracket even if not necessary, even just because this permits me to set crystal clear my intentions. And this is even more needed in a language like Xojo, where many “automatisms” are in place, like implicit type conversions. The whole discussion started from a piece of code I found and that puzzled me for the results.
Code from others is always interesting. You learn a lot, in what you can do, and in what you shouldn’t.