The If.. commands should be removed, as they can be easily be rewritten with literal Ifs. Also, I would simply not accept ifs without Braces "()", and throw a Compiler/Interpreter Error.
Legacy commands to consider keeping (for convenience): IfWinActive, IfWinExist, IfInString, IfExist. I personally don't find IfInString all that convenient. Should it be kept? Should the others be kept?
For AHK v2 I recommend to remove the Commands completly and replace them with Build-In Methods. Anything other confuses newbies.. For compatibility, I would add Function-command support to the current AHK_L branch so both is allowed. Also mark all Commands as Obsolete which is actually also the strategy of IA.
As a substitute for SetFormat (which has been removed), I've included a script function for formatting strings. Take a look in Lib\format.ahk for a description of the syntax. It is basically a mixture of .NET's String.Format function and the C runtime's format specifiers. Any comments or suggestions about the syntax are welcome. Once the syntax is finalized, I'll add a built-in function.
Similarly, I plan to replace If Var is [not] type with a new "is" operator
About IA UriDownload: A very often seen task is to download some text (html) from the internet, so the initial behavior should be that UriDownload is a function which returns the downloaded data. To support binary data / large Data there is also support for writing it into a file. The naming changes were initially thought to not break existing scripts. URLDownloadToFile calls internaly UriDownload for compatibility.
Are there any objections to renaming URLDownloadToFile to just Download?
I notice that IronAHK has a "UriDownload" function, but I wonder what the point was.
My understanding is that a URL is a specific type of URI which includes information about how to locate the resource.
To download something, you need to know where it is and how to get it; i.e. you need a URL. Either way, "URI" or "URL" seems unnecessary.
Also, for automating purposes POST Parameter support is planed, so it would be gread when IA/AHK v2 Syntax stay together. Any plans to support POST params, maybe also build in Cookie support?
There might be some optimization potential to AHKs window Class/ID handling. I'm currently rewriting the IA Linux X11 implementation, and there are some things which would be great if AHK puts some more abstraction in it, so scripts can run better on both platforms.
The primary idea should be to define a AHK V2 SYNTAX - which Interpreter/Compiler is used shouldn't matter. That said, I would welcome a Syntax Definition, Command Library Overview, even when some things currently arn't implemented. This would it make much easier to have IA near AHK (v2). Like yet, some detailed destination where AHK v2 will go.
The main Problem I had with AHK_L was, that you've added things without first defined where you want to go.
Last but not least: Any plans to support optional typing of variables?
* IDE can provide Member listing help (Intelisense), instant validating
* Method parameters can be validated by IDE
* Optional means: Newbies doesn't have to care about but Pros can speed up code, better overview in bigger projects
It's not necessary that typed Variables are handled as native type, if AHKv2 did not has the matching Code Design, but IDE support will make Coding much more comfortable and faster. Also, misspelling errors which are very often cause for AHK Script errors can be detected on any minimal Intellisense Logic.
This is a very important point for me, I would be interested to discuss this point in detail - maybe in a separate thread or over email.