24 replies to this topic

[CephasOz]

This is the lack of civility of which I originally wrote. Your language is emotionally charged - "pathetic", "childish", "selfish", "retort", "hiding behind", and "unwilling to listen", are not part of a good reasoned argument. I am not attacking you; I am offering an opinion based on decades of experience.

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

<{POST_SNAPBACK}>

[Valik]

This is the lack of civility of which I originally wrote.  Your language is emotionally charged - "pathetic", "childish", "selfish", "retort", "hiding behind", and "unwilling to listen",  are not part of a good reasoned argument.  I am not attacking you; I am offering an opinion based on decades of experience.

<{POST_SNAPBACK}>

I've stated my arguments multiple times. I started out civil. I explained why it couldn't be implemented. You persist in saying that it should be added, contrary to my arguments on why it can't. I strongly dislike explaining something twice to a person. In your case, I have explained multiple times from multiple angles times two; once on the mailing list and once here. You have persisted to request this feature even after having an explanation on why it is not currently something that can be implemented correctly. Anybody reading this thread, just the same as the mailing list, can see that I started out explaining quite verbosely on why this can't be implemented as you suggest. If I recall, on the mailing list, the discussion ended when others chimed in that I had went out of my way to explain this to you multiple times and you were continuing to carry on about it seemingly ignoring my just arguments.

With that said, you don't deserve civility from me if you do not properly process the things I direct at you. I do not know what your true reason for not abandoning this idea is, however, in my opinion, when anybody is given sufficient evidence on why something is not possible, yet they persist in carrying on, this demonstrates childish behavior to me. Specifically:
Child: "Can I have this toy?"
Parent: "No"
Child: "Why not?"
Parent: "Because"
Child: "But I want it"
Parent: "I said no"
Child: *Cries/throws a fit/acts up in general*
Parent: *Threatens with punishment*

Alternatively, it also appears selfish. You are, for whatever reason, refusing to accept that there are multiple facets to implementing a macro and you are only concerned with the assignment aspect. There is another fundamental aspect to this which you so casually brush off as (para-phrased), "People shouldn't do that anyway". If you really do have decades of experience, you should be able to see how "pathetic" a reason this is for us to fail to implement something properly. If you really do have decades of experience, you should know by now that you are in fact, not the chief of the Style Police and that people can write code however they wish, including, but not limited to explicitly comparing boolean values, despite it being redundant. Your comments demonstrate that you are not concerned about how others write code and believe that your methods are the de facto standard by which code should be written. Those who wish to write code different than you are lumped into the category of "They shouldn't do that".

Therefore, my posts are not so much emotionally charged as they are full of adjectives which come to mind as a result of reading your posts. Most people, upon obtaining a post detailing why a particular feature can't/won't be implemented either give up the idea or offer suggestions of alternative ways to work around whatever problems there may be. You, on the other hand, half done neither of these things. To compound the annoyance even further, the request you have made is something that can be done with the language itself in its current form. It is a scripting language after all, not an "everything <insert user> needs is built-in". Given the minimal amount of effort required to implement two constants to represent the values of true and false, nobody can fault AutoIt for not having built-in values for this if they can't meet the definition the language sets for.

[CephasOz]

I am forced to conclude that you will never agree with me, however good my arguments. Likewise, you will have to deal with the fact that I will never agree with you, however specious or uncivil your arguments. End of discussion.

I've stated my arguments multiple times.  I started out civil.  I explained why it couldn't be implemented.  You persist in saying that it should be added, contrary to my arguments on why it can't.  I strongly dislike explaining something twice to a person.  In your case, I have explained multiple times from multiple angles times two; once on the mailing list and once here.  You have persisted to request this feature even after having an explanation on why it is not currently something that can be implemented correctly.  Anybody reading this thread, just the same as the mailing list, can see that I started out explaining quite verbosely on why this can't be implemented as you suggest.  If I recall, on the mailing list, the discussion ended when others chimed in that I had went out of my way to explain this to you multiple times and you were continuing to carry on about it seemingly ignoring my just arguments.

With that said, you don't deserve civility from me if you do not properly process the things I direct at you.  I do not know what your true reason for not abandoning this idea is, however, in my opinion, when anybody is given sufficient evidence on why something is not possible, yet they persist in carrying on, this demonstrates childish behavior to me.  Specifically:
Child: "Can I have this toy?"
Parent: "No"
Child: "Why not?"
Parent: "Because"
Child: "But I want it"
Parent: "I said no"
Child: *Cries/throws a fit/acts up in general*
Parent: *Threatens with punishment*

Alternatively, it also appears selfish.  You are, for whatever reason, refusing to accept that there are multiple facets to implementing a macro and you are only concerned with the assignment aspect.  There is another fundamental aspect to this which you so casually brush off as (para-phrased), "People shouldn't do that anyway".  If you really do have decades of experience, you should be able to see how "pathetic" a reason this is for us to fail to implement something properly.  If you really do have decades of experience, you should know by now that you are in fact, not the chief of the Style Police and that people can write code however they wish, including, but not limited to explicitly comparing boolean values, despite it being redundant.  Your comments demonstrate that you are not concerned about how others write code and believe that your methods are the de facto standard by which code should be written.  Those who wish to write code different than you are lumped into the category of "They shouldn't do that".

Therefore, my posts are not so much emotionally charged as they are full of adjectives which come to mind as a result of reading your posts.  Most people, upon obtaining a post detailing why a particular feature can't/won't be implemented either give up the idea or offer suggestions of alternative ways to work around whatever problems there may be.  You, on the other hand, half done neither of these things.  To compound the annoyance even further, the request you have made is something that can be done with the language itself in its current form.  It is a scripting language after all, not an "everything <insert user> needs is built-in".  Given the minimal amount of effort required to implement two constants to represent the values of true and false, nobody can fault AutoIt for not having built-in values for this if they can't meet the definition the language sets for.

<{POST_SNAPBACK}>

[Fergus]

<snip>
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}>

I can't quite agree with you there, Ejoc, lol. The explicit use of True can add emphasis on occasion.

If $TheMotherInLawsADragon Then Say ("Yes")
If $TheMotherInLawsADragon == $True Then Say ("Yes! True, so True.")

;-)

[tylo]

I can't quite agree with you there, Ejoc, lol. The explicit use of True can add emphasis on occasion.

If $TheMotherInLawsADragon Then Say ("Yes")
If $TheMotherInLawsADragon == $True Then Say ("Yes! True, so True.")

;-)

<{POST_SNAPBACK}>

In the latest beta True and False are new keywords. The following will work:

$TheMotherInLawsADragon = 5 ; implies True
If $TheMotherInLawsADragon Then Say ("Yes")
If $TheMotherInLawsADragon = True Then Say ("Yes! True, so True.")

Using the == operator will *not* work, as that is exclusively for string comparison.