| View previous topic :: View next topic |
| Author |
Message |
engunneer
Joined: 30 Aug 2005 Posts: 5957 Location: Pacific Northwest, US
|
Posted: Tue Apr 29, 2008 5:29 pm Post subject: Legacy IfEqual |
|
|
Split from : Sticky keys
I would avoid the legacy If statements (IfEqual). They may be slightly faste, but they are becoming deprecated. In the event that AHK v2 comes out, they will no longer be in the language. _________________
Unless otherwise noted, all code is untested.
Common Answers: 1.(Loops, Viruses, etc.) 2. Search 3.RTFM
Last edited by engunneer on Tue Apr 29, 2008 6:39 pm; edited 1 time in total |
|
| Back to top |
|
 |
[VxE]
Joined: 07 Oct 2006 Posts: 702
|
Posted: Tue Apr 29, 2008 5:37 pm Post subject: |
|
|
Good to know, but I like the one-liner capability of the legacy ifs for a 'code golf' thing.
But (cmiiw) the AHK interpreter takes IfEqual, Var, 2, command and turns it into
If Var = 2
command _________________ My Home Thread
More Common Answers: 1. It's in the FAQ 2. Ternary ( ? : ) guide 3. Post code with [code][/code] tags |
|
| Back to top |
|
 |
engunneer
Joined: 30 Aug 2005 Posts: 5957 Location: Pacific Northwest, US
|
Posted: Tue Apr 29, 2008 6:16 pm Post subject: |
|
|
If var = 2 is still 'legacy'
If (var = 2) is not. _________________
Unless otherwise noted, all code is untested.
Common Answers: 1.(Loops, Viruses, etc.) 2. Search 3.RTFM |
|
| Back to top |
|
 |
Razlin
Joined: 05 Nov 2007 Posts: 230 Location: canada
|
Posted: Tue Apr 29, 2008 6:22 pm Post subject: |
|
|
Just a note..
Where do you guys find out what is legacy and what is not, as well as AHK2 _________________ -=Raz=- |
|
| Back to top |
|
 |
engunneer
Joined: 30 Aug 2005 Posts: 5957 Location: Pacific Northwest, US
|
Posted: Tue Apr 29, 2008 7:20 pm Post subject: |
|
|
I can't find where I've referenced this information. It's been discussed a bit in the forum (new version features) _________________
Unless otherwise noted, all code is untested.
Common Answers: 1.(Loops, Viruses, etc.) 2. Search 3.RTFM |
|
| Back to top |
|
 |
Oberon
Joined: 18 Feb 2008 Posts: 408
|
Posted: Tue Apr 29, 2008 7:28 pm Post subject: |
|
|
| engunneer wrote: | | If (var = 2) | Since = will replace := that expression will always return true so it's technically incorrect, use if (var == 2) instead. Traditional non-expression if statements are typically 50% faster which make them my preferred method for performance critical scripts. _________________
 |
|
| Back to top |
|
 |
[VxE]
Joined: 07 Oct 2006 Posts: 702
|
Posted: Tue Apr 29, 2008 11:08 pm Post subject: |
|
|
| Code: | Add, Var, -0x2
BR NP, Label
MsgBox, Var equals 2
Label:
Stop |
RAWR!
| Oberon wrote: | | use if (var == 2) instead | Yeah, but what if 'var' contains an upper-case '2' ??  _________________ My Home Thread
More Common Answers: 1. It's in the FAQ 2. Ternary ( ? : ) guide 3. Post code with [code][/code] tags |
|
| Back to top |
|
 |
Oberon
Joined: 18 Feb 2008 Posts: 408
|
Posted: Tue Apr 29, 2008 11:25 pm Post subject: |
|
|
| [VxE] wrote: | | what if 'var' contains an upper-case '2' | It is my understanding that StringCaseSense will be extended to affect this. Before you ask, yes, !== will have to be implemented too as a result. I hope AutoHotkey follows other dynamic typed scripting languages like PHP and JavaScript by further allowing strict equality operators (i.e. === and !===). _________________
 |
|
| Back to top |
|
 |
Lexikos
Joined: 17 Oct 2006 Posts: 2359 Location: Australia, Qld
|
Posted: Thu May 01, 2008 9:47 am Post subject: |
|
|
| Oberon wrote: | | engunneer wrote: | | If (var = 2) | Since = will replace := that expression will always return true so it's technically incorrect, | Not necessarily. Despite the results of the poll, it seems = will be context-sensitive.
| Chris wrote: | Thanks for the feedback. I agree that a dual-purpose equal-sign can lead to bugs when code is modified or copied-and-pasted without attention to context. However, the following reasons seem to outweigh that:
1) Treating if x = y as an assignment would probably cause a lot more bugs than the above. This is because most AutoHotkey users have no C-like experience, and even those who do tend to use the wrong operator sometimes.
2) Treating a line consistingly merely of x=y as a syntax error or a do-nothing statement is counterintuitive and harms productivity.
This leaves few options other than the context-sensitive equal sign. | I think #1 applies equally to if (x = y). |
|
| Back to top |
|
 |
Oberon
Joined: 18 Feb 2008 Posts: 408
|
Posted: Thu May 01, 2008 10:05 am Post subject: |
|
|
| Lexikos wrote: | | Despite the results of the poll, it seems = will be context-sensitive. | *sigh* so it is true what they say about open source developers... _________________
 |
|
| Back to top |
|
 |
[VxE]
Joined: 07 Oct 2006 Posts: 702
|
Posted: Thu May 01, 2008 7:01 pm Post subject: |
|
|
Since AHK is an interpereted language anyways, why not have a "#" directive (the kind that gets handled pre-run-time, or whatever) to allow a script author to specify an explicit assignment operator ? Maybe even another one for boolean equals
i.e. something like this: | Code: | #AssignmentOperator, =
#CaseSensitiveBooleanEqualToOperator, ==
#CaseInsensitiveBooleanEqualToOperator, ~= |
Even though the default context-based (equals/assignment) operator would be just fine most of the time, having the option available would allow coders with different language backgrounds to adjust AHK to be more comfortable for them.
Unless version 2 is going to be as confusing as | Code: | | #SingleInstance, Usually |
Anyways | Code: | Toggle = Toggle = False
;intended as: Toggle := (Toggle == False) |
should not be an ambiguous statemtent in V2.0 _________________ My Home Thread
More Common Answers: 1. It's in the FAQ 2. Ternary ( ? : ) guide 3. Post code with [code][/code] tags |
|
| Back to top |
|
 |
Tuncay
Joined: 07 Nov 2006 Posts: 379 Location: Berlin
|
Posted: Thu May 01, 2008 10:08 pm Post subject: |
|
|
| Quote: | Since AHK is an interpereted language anyways, why not have a "#" directive (the kind that gets handled pre-run-time, or whatever) to allow a script author to specify an explicit assignment operator ? Maybe even another one for boolean equals
i.e. something like this:
| Code: | #AssignmentOperator, =
#CaseSensitiveBooleanEqualToOperator, ==
#CaseInsensitiveBooleanEqualToOperator, ~= |
|
Which character sequence to use would not make really a difference in language design. The language should not be modifiable in the core, so to avoid some problems.
Also such a construct would make a script less readable and less portable, especially if the source is public. What would be if the source is included in another source with such a construct? And what about same sequence defintition?
A real dynamic operator would not be possible in that case. No this is not any help to the scripter. The language should be defined unvariable in the syntax. |
|
| Back to top |
|
 |
[VxE]
Joined: 07 Oct 2006 Posts: 702
|
Posted: Fri May 02, 2008 6:17 am Post subject: |
|
|
| Tuncay wrote: | Also such a construct would make a script less readable and less portable, especially if the source is public. What would be if the source is included in another source with such a construct? And what about same sequence defintition?
A real dynamic operator would not be possible in that case. No this is not any help to the scripter. The language should be defined unvariable in the syntax. |
It's too bad you feel that way.
IMHO, each operator should have a single function, regardless of where it appears in a script,... and allowing a script author to specify which does what would be icing on the cake.
btw: a simple RegexReplace is all it would take to turn a script with tweaked operators back into a "standard" form. _________________ My Home Thread
More Common Answers: 1. It's in the FAQ 2. Ternary ( ? : ) guide 3. Post code with [code][/code] tags |
|
| Back to top |
|
 |
Oberon
Joined: 18 Feb 2008 Posts: 408
|
Posted: Fri May 02, 2008 10:24 am Post subject: |
|
|
I agree with Tuncay. Giving operators variable meaning would spell an endless source of bugs and confusion. Learning would be difficult for newbies if the syntax is too volatile and takes different forms. A prime example: ~ is a unary NOT operator but you override it to a "CaseInsensitiveBooleanEqualToOperator". Productivity for expert users would be decreased as they'd be forced to conform to a standard if they have a stdlib script pending release.
| [VxE] wrote: | | btw: a simple RegexReplace is all it would take to turn a script with tweaked operators back into a "standard" form. | Not true. You can have operators within strings, heredoc paragraphs or part of very complex expressions which cannot be parsed with a regex. Remember AutoHotkey is an interpreter, so any rule which needs to added to the lexical parsing routines will delay script launch times and increase memory footprint regardless of whether they're used or not. _________________
 |
|
| Back to top |
|
 |
[VxE]
Joined: 07 Oct 2006 Posts: 702
|
Posted: Fri May 02, 2008 11:19 am Post subject: |
|
|
| Oberon wrote: | | A prime example: ~ is a unary NOT operator but you override it to a "CaseInsensitiveBooleanEqualToOperator". |
You misread my example.
None of my examples suggested overriding any other defined operator with an unrelated function. The ~= operator is 'borrowed' from another scripting language, where it represents the "non-case-sensitive boolean equals" operator.
My main point -> Specifying different operators for "assignment" and "boolean equal to (exact)" and "boolean equal to (case insensitive)" can only serve to reduce confusion. (Who actually decides what the operators are is irrelevant to this point)
My sub-point -> Allowing a script's author to tweak the effective operators for a particular script would be cool, though implementation of such a feature would present usability issues. _________________ My Home Thread
More Common Answers: 1. It's in the FAQ 2. Ternary ( ? : ) guide 3. Post code with [code][/code] tags |
|
| Back to top |
|
 |
|