Re: Keysharp - the resurrection of IronAHK
Posted: 18 Sep 2021, 00:24
I'm back with a big update. Before I get into it, I am pushing back the initial publication of the code from October to November/December. These last few parts are proving to be rather difficult.
#directives are done, with support for inline variables such as:
These #directives also include some new ones that are not present in AHK. They allow you to set the various Assembly Info fields that C# supports included in this example:
Functions are done with support for global, local, and static variables, as well as parameters and default parameters. Nested functions are not supported yet, I will punt on those until later.
All of the above have been unit tested.
I will work on Labels/goto next.
In addition to the above, here is a detailed technical update about what else I've been working on. Keep reading if you enjoy the nitty gritty details.
I've made some fundamental changes to how variables are handled. The code I inherited from IronAHK kept all variables in a map, and looked them up via string. So to get the value of your variable x, the generated code would be Vars["x"].
Inside the [] operator was a lock, and a map (Dictionary<K, V> in C#) lookup. While this normally wouldn't matter, if you were doing millions of variable accesses, it would impact performance.
In addition, it tried to manage scope with a complex string/naming scheme where each scope level was delimited by a period '.'
So if you had a variable x in a function named func(), it would be referred to as "func.x"
The pro of this design was that all variables were %dynamically% accessible.
I started running into problems when implementing the global/local/static variables in functions. So I pivoted and decided to completely redo how variables are declared, read from and written to.
Variables are now just normal C# variables of type object. So if you declare
in your script, it will translate to the following line in C#:
This should greatly enhance performance, and also will relieve me of having to manage the scoping/lifetime behaviors of each variable. The built in C# language rules will handle that now.
The downside is that variables will now only accessible by dynamic lookup if they are global. Function variables will no longer be accessible dynamically. For example:
Will work fine if those are global variables. The result is that y11 would have the value 123.
However, y%x% will not work if they are function variables, such as:
The reason being is that C# cannot look up local function variables by name using reflection.
I hope this is not a deal breaker.
#directives are done, with support for inline variables such as:
Code: Select all
#Include "%A_ScriptDir%"
These #directives also include some new ones that are not present in AHK. They allow you to set the various Assembly Info fields that C# supports included in this example:
Code: Select all
#ASSEMBLYTITLE This is a title!
#ASSEMBLYDESCRIPTION This is a description!
#ASSEMBLYCONFIGURATION This is a config!
#ASSEMBLYCOMPANY This is a company!
#ASSEMBLYPRODUCT This is a product!
#ASSEMBLYCOPYRIGHT This is a copyright!
#ASSEMBLYTRADEMARK This is a trademark!
#ASSEMBLYVERSION 9.8.7.6
Functions are done with support for global, local, and static variables, as well as parameters and default parameters. Nested functions are not supported yet, I will punt on those until later.
All of the above have been unit tested.
I will work on Labels/goto next.
In addition to the above, here is a detailed technical update about what else I've been working on. Keep reading if you enjoy the nitty gritty details.
I've made some fundamental changes to how variables are handled. The code I inherited from IronAHK kept all variables in a map, and looked them up via string. So to get the value of your variable x, the generated code would be Vars["x"].
Inside the [] operator was a lock, and a map (Dictionary<K, V> in C#) lookup. While this normally wouldn't matter, if you were doing millions of variable accesses, it would impact performance.
In addition, it tried to manage scope with a complex string/naming scheme where each scope level was delimited by a period '.'
So if you had a variable x in a function named func(), it would be referred to as "func.x"
The pro of this design was that all variables were %dynamically% accessible.
I started running into problems when implementing the global/local/static variables in functions. So I pivoted and decided to completely redo how variables are declared, read from and written to.
Variables are now just normal C# variables of type object. So if you declare
Code: Select all
x := 3
Code: Select all
object x = 3;
The downside is that variables will now only accessible by dynamic lookup if they are global. Function variables will no longer be accessible dynamically. For example:
Code: Select all
x := 11
y11 := 99
y%x% := 123
However, y%x% will not work if they are function variables, such as:
Code: Select all
func()
{
x := 11
y11 := 99
y%x% := 123
}
I hope this is not a deal breaker.