24 replies to this topic

[CephasOz]

I've raised this in Yahoo groups, but the chat got very heated, so I'll raise it here where we are guaranteed more civility.

We need to have @True and @False macros because it allows us to initialise variables meaningfully:
$bCondition = @False
which is far more meaningful than:
$bCondition = 0

Conditions should be tested without an equality:
If $bCondition Then
--and not --
If $bCondition == 1
so it doesn't matter what value @True has, just so long as it's not 0.

For those who say that true could be any value, I would say that it doesn't matter what that value is, since it's never tested, it's only used for assignment.

If you're going to test like so:
If ( $bCondition == @True ) Then
the "== @True" is redundant and superfluous. You may as well code:
If ( ( ( ( $bCondition == @True ) == @True ) == @True ) == @True ) Then
to as many levels as you like because anything past:
If $bCondition Then
is unnecessary and bad coding practice.

Likewise, you would never say:
If $bCondition == @False Then
instead, you would say:
If Not $bCondition Then

Now, as to what value @True would be set to in AutoIt, why not set it to 1?
Implicity, AutoIt uses the value 1 as true anyway, as in:
If ( 387 == 387 ) Then
The test evaluates to 1, as does any true test. So true is already recognised as 1. Why not make @True equal to it as well? (Not that it matters - it could just as easily be 26, or 1024, or 785.)

[CyberSlug]

This has been mentioned before.
@False would work
However, @True will not work becuase it would need to simultaneously equal all non-zero numbers

If (1 == @True) Then ...???
If (2 == @True) Then ...???
If (3 == @True) Then ...???

[SlimShady]

This should be possible to make. As Valik said "nothing is impossible".
@True would be NOT 0
@False would be 0
@True = NOT @False
@False = NOT @True

this:

If (1 == @True) Then ...???
If (2 == @True) Then ...???
If (3 == @True) Then ...???

can be translated to:

If (1 == NOT @False) Then ...???
If (2 == NOT @False) Then ...???
If (3 == NOT @False) Then ...???

and is the same as:

If (1 == NOT 0) Then ...???
If (2 == NOT 0) Then ...???
If (3 == NOT 0) Then ...???

Wait a minute... You are talking about comparing strings in statements.
When a script compares any number other than 0 to @True, the interpreter should return true.
But it's just plain stupid. Why would you compare strings to those macros?
IMO AutoIt should error out and tell the user: "You're stupid"

[CyberSlug]

Why would you compare strings to those macros?
IMO AutoIt should error out and tell the user: "You're stupid"

<{POST_SNAPBACK}>

If (ResultOfSomeFunctionThatReturnsAValue() = @True) Then....

[CyberSlug]

If (1 == NOT @False) Then ...???
If (2 == NOT @False) Then ...???
If (3 == NOT @False) Then ...???

I believe you meant to say the following:

If ( NOT(1 == @False) Then ...???
If ( NOT(2 == @False) Then ...???
If ( NOT(3 == @False) Then ...???

[SlimShady]

If (1 == NOT @False) Then ...???
If (2 == NOT @False) Then ...???
If (3 == NOT @False) Then ...???

I believe you meant to say the following:

If ( NOT(1 == @False) Then ...???
If ( NOT(2 == @False) Then ...???
If ( NOT(3 == @False) Then ...???

<{POST_SNAPBACK}>

They are both OK.

NOT @False = @True

In the above examples 1 2 3 are all @True.
Your examples:

If ( NOT(1 == @False) Then ...???
If ( NOT(2 == @False) Then ...???
If ( NOT(3 == @False) Then ...???

can be translated as:

If ( NOT(@True == @False) Then ...???

which is the same as:

If NOT @False Then  ;result is true

BTW
@CyberSlug
You are the one who made me realise and discover how the above works.
"Boolean Challenge" Remember?
Thank you for that.

Edited by SlimShady, 17 March 2005 - 02:36 PM.

[Valik]

First of all, I'm still here, so wherever you got the notion things are guaranteed to be civil, I don't know, but it's wrong. The odds are significantly lowered that I'll be civil given that I explained this thoroughly on the Yahoo group and even everybody who jumped into the thread at the end agreed that I did a thorough (and patient) job explaining it to you when you absolutely refused to listen to the logic I presented.

I'll say it one more time:
Regardless of good/bad coding habits or whether you should/shouldn't do it, the following conditions must all behave as expected with the definition of "true" being anything non-zero.

If 1 = @True
If 2358392 = @True
If -12489 = @True
If 0 <> @True

I don't care that people shouldn't do that. People shouldn't use Call() except under very rare circumstances, but I see them use it all the time (incorrectly). If it's there, people will do it. I see Blue_Drache sometimes uses "If Function() = 1" to check a return value. Superfluous? Absolutely, but it's still being used and he's not the only one. This is not a macro you are going to see any time soon unless somebody has a sudden brainstorm.

Stop thinking of yourself on this and actualy listen to the same arguments I gave you a few months ago which everybody else seemed to find reasonable except you.

As for the reason I grew annoyed and lost civility the first time around, it's like explaining something to a child. I explained until I was blue in the face yet you still insisted you were right, not actually giving any consideration to any of the valid arguments I was presenting. Now I'm not so sure you didn't just drop the subject to avoid conflict rather than actually understanding what I've said. I can say with a lot of certainty that you won't find me any more civil here on this subject than on the Yahoo! list. More than likely, I will be less civil. Not only have I gone over this subject before, I've gone over it with you and having to explain something multiple times to the same person really wears my thin patience out.

And Blue_Drache, sorry to drag you under the bus on your coding practice. You're just the first person who popped to mind as I remember seeing some bit of code you wrote using what I explained.

[SlimShady]

It's definitely a useless addition. I agree.

[Ejoc]

Regardless of good/bad coding habits or whether you should/shouldn't do it, the following conditions must all behave as expected with the definition of "true" being anything non-zero.

If 2358392 = @True
If -12489 = @True

I'm not sure of your programming background, but these two statements dont make sense to me. Does any other programming language work this way? Typically True and Flase are 1 and 0, so checking if 2358392 is true just doesnt make sense to me, you are basicly testing 2 different data types, just say it out loud "If 5 is true..."

Those tests should result in 'comparing incompatible data types'

And if you HAD to preform a test like that, you should typecast it to boolean.
Something like:

If Boolean(2358392) = @TRUE

Func Boolean($b)
If $b <> @FLASE Then 
return @TRUE
Else
return @FALSE
Endif
EndFunc

[Valik]

Its been my experience that languages not supporting a boolean type denote "true" as -1, not 1.

C++ does in fact allow you to compare int's and bool's, you just have to cast the int to a bool (Even then it warns if using a variable). We don't have the luxury of types in AutoIt, so a warning is impossible to generate. There is no way to alert AutoIt ahead of time that a variable is going to be a boolean value and there is no way to deduce that come time to process the If statement or whatever the case may be. Were it possible to figure out just-in-time that we needed to cast to a boolean and compare against a @True macro with a pre-defined value, that would be fine. However, we can't. The internal architecture makes such a thing difficult to do since the language was designed to be typeless.

So, since the comparison aspect shouldn't be used and can't be implemented anyway, that means @True/@False just become syntactic sugar for assignments only. However, that isn't a compelling argument anymore since the advent of the Const keyword. So now it's quite simple to put this in any script:

Global Const $TRUE = -1, $FALSE = 0

Voila, instant, immutable variables that represent true and false. Anybody too lazy to put 35 characters in their script when they need tangible representations of true and false should probably just bow out of the scripting/programming game now before they really have to do some work.

This sampe C++ program shows an example of comparing a number to boolean true via a type-cast. It's not possible to implicitly or explicitly typecast with AutoIt. This code doesn't even generate a warning. However, using a variable instead of a numeric constant would generate a compiler warning (I'm going to assume the compiler does the type-cast and converts it to a bool instead of it being cast at run-time which would produce a performance hit, which is what the warning is about).

#include <iostream>
#include <cstdlib>  // For system()

int main()
{
    if ((bool)23895832 == true)
        std::cout<<"Cast allows this to print"<<std::endl;
    else
        std::cout<<"Should not print"<<std::endl;
    system("PAUSE");
    return 0;
}

[Ejoc]

As I was going to bed last night I started thinking about it more and having True Not be 0 made sense too me at assembly level.

If 5 = @TRUE Then
;true code
Else
;false code
Endif

If the test condition is being translated to something like

mov ax, 5        ; load 5 into register a
   cmp ax, 0         ; compare it to 0
   jz @@false_code   ; if its 0 jump to  @@flase_code
 ;true code        ; it wasnt 0 do whatever
   ret             ; return
@@false_code:
 ;false code          ; it was 0 do whatever
   ret             ; return

Then having True be non-zero makes sense.

Edited by Ejoc, 18 March 2005 - 06:28 PM.

[Valik]

AutoIt doesn't compile into assembly/machine code, it's all in C++ which means the code in AutoIt isn't going to translate to anything like your assembly example.

[Ejoc]

AutoIt doesn't compile into assembly/machine code, it's all in C++ which means the code in AutoIt isn't going to translate to anything like your assembly example.

<{POST_SNAPBACK}>

"Someone" AutoIt/C++ compiler has to generate machine code for the computer to execute the script, but my point wasnt that AutoIt *needs* too, just that if the test condition is like my example anything but 0 equates to true.

I havent looked into how AutoIt executes its scripts, but if its generating C++ code, then you should be able to take the generated C++ code and compile it w/ the argument(cant remember it -S maybe) that will generate the assembly code used and one could see how the computer is actually preforming the test.

Actually and easy solution would be fore AutoIt to ingnore the = @true

If $variable = @TRUE Then

Since

If $variable Then

already works

Now that I think about it, I dont care. As long as 'If $variable Then' works I would NEVER type out 'If $variable = @TRUE Then' since they both are equally easy read, execute the same, and less typing.

Edited by Ejoc, 18 March 2005 - 10:56 PM.

[SlimShady]

Actually and easy solution would be fore AutoIt to ingnore the = @true

If $variable = @TRUE Then

Since

If $variable Then

already works

Now that I think about it, I dont care.   As long as 'If $variable Then' works I would NEVER type out 'If $variable = @TRUE Then' since they both are equally easy read, execute the same, and less typing.

<{POST_SNAPBACK}>

That's exactly the reason why adding these macros is useless and unnecessary.
I believe the word is redundant.

[zcoacoaz]

these would pretty much be macros for newbies who are to lazy to figure out 0=false and not 0=true so they put @False or @True if these are added they will mostly just give people bad coding habits

[CephasOz]

That's exactly the reason why adding these macros is useless and unnecessary.
I believe the word is redundant.

<{POST_SNAPBACK}>

As I said in my original post, the macros are only used in assignment, example:

$bCondition = @True
$bCondition = @False

to make code more readable. They are not used in testing because they are redundant. Therefore, you wouldn't code:

If ( $bCondition == @True ) Then
If ( $bCondition == @False ) Then

instead, you would treat a Boolean as a Boolean, and say:

If $bCondition Then
If Not $bCondition Then

The macros are needed to make code more readable. What shows the intent of the code better:

$bCondition = 1
$bCondition = -1
$bCondition = 1768
$bCondition = 0x1
$bCondition = 1e0

or

$bCondition = @True

[zcoacoaz]

how long have you been coding in autoit?

[CephasOz]

how long have you been coding in autoit?

<{POST_SNAPBACK}>

I have been coding in AutoIt 2 & 3 for a few years now. (You will find references to my posts in Yahoo groups if you look for them, and some of the UDFs that come with AutoIt3 are mine.) I have been coding in many different languages for over 35 years.

=========================================

Let me explain the IF test thing so it's easier to understand.

1) IF/ENDIF, WHILE/WEND, and DO/UNTIL require Boolean values to function.

2) A numeric variable is tested using an operator to produce a Boolean, that is, TRUE or FALSE. For example:

$iVal = 1
If ( $iVal < 5 ) Then

would produce a value of TRUE.

3) A string variable is tested using an operator to produce a Boolean, that is, TRUE or FALSE. For example:

$sVal = "Hullo World"
If ( $sVal == "Hullo World" ) Then

would produce a value of TRUE.

4) It is not necessary to do anything to a Boolean variable since it is already TRUE or FALSE. For example:

$bVal = @True
If $bVal Then

Notice - no operator, but the IF/ENDIF has the Boolean that it requires.

5) Since an operator is only necessary when producing a Boolean value from a non-Boolean variable, operators are not used with Boolean variables with the exception of the inverter NOT, and then only to turn a FALSE into a TRUE or vice-versa. For example:

$bFound = @False
While Not $bFound

The ONE operator that it makes sense to use with a Boolean, but even that doesn't involve the @True or @False macros.

6) Therefore, I repeat, the @True and @False macros are only used for assigning a value, they are not used in testing since it doesn't make sense to do any testing on a Boolean.

[zcoacoaz]

i guess i sort of understand better why you would want them now

[Valik]

It doesn't make sense to request @True/@False macro's for any reason since there is a Const keyword, so creating Global immutable variables is possible and can be done by the user, thus avoiding the hassle of trying to explain to somebody who refuses to listen to completely valid arguments on why a macro can't just implement half the functionality required.

This is the exact same reason I lost patience and "civility" with you on the mailing list. I explain to you until I'm blue in the face and you retort with, "But people shouldn't use it for comparison" every single time. There is a massive amount of difference between "shouldn't" and "won't".

I strongly encourage you to drop this entire subject. We've been through this once. I think it's quite pathetic that you re-posted this on the forum after I explained to you on the mailing list as to why a macro wouldn't work. Your agument is just as pathetic and shows you unwilling to listen to the reasons why it won't work. You're just being selfish and childish in requesting something so simple you can implement it already in your own code. I don't know why you're hiding behind the excuse that it makes code easier to read but I'm not buying that one as these two lines are no harder to read than the other:

$bVar1 = @TRUE
$bVar2 = $TRUE

where $TRUE and $FALSE are defined as:

Global Const $TRUE = -1, $FALSE = 0