AutoHotkey Community

Because the key names are saved in a list. Later on other commands, first the requested key will be looked up in that list. So no need for other validation process here.



Yes. One of the main goals with $() are to catch all possible Error Types and write back an Error Code to ErrorLevel.

Another thing is to restrict the names more than AutoHotkey it does. Look at this RegEx for validation:

• Most reason here is, that a key cannot consist of a number only. Any number is treated as an index (later at get and set commands).
• Less special chars is future save. May be the user want extract data to convert into other format.
• Special chars can be used for special cases. For example to guarantee not to interfere with other variables. Take the "$" character for example, it is used to delimit key name and namespace. Also that way they cannot be interfered with local variable names.

There are some things I want to mention. First, here is namespace support integrated. So creating keys in different namespaces are supported; all namespaces comes with own keylists and indexes.
Creating keys in a list should work faster, I think.May be its slower, this should be Benchmarked also.
Also there are some other commands available. And there is another command in planning: deref (like Transform, Deref).

Thx for the tips and your effort.

The get command neither validates the key nor uses the key list.
By "run-time error" I was referring to an AutoHotkey error dialog, showing a message such as:
Clearly, $() does not catch all possible errors.
I wasn't questioning validation in general.
It is faster (by perhaps 20%), since each item would otherwise incur the overhead of a function call. I'm not sure how useful it is to initialize every item to the same value, though.

Last Changes, Version 0.6

• some small performance optimizations
• new commands available: "deref" and "getaddress"

deref-command usage example:


The get command itself does not validate... lol but look at the if structure. There are some checks before it comes to the get-command. If all checks are ok, then the get-command (and others) sets ErrorLevel to 0 finally.

There are many Return statements, so after Error occurrence, ErrorLevel will be set and return from that point is done. (Exception from this rule is by create lists... where ErrorLevel is raised up 1 one and continue creation.)

Normally I hate multiple Returns ... but this is an optimization reason in speed.


Ok, in that point your`e right. But if the validation on create process fails, the key is not in list and cannot be found on get or other commands later. Another error is found ("key not found").

By mean of "catching all possible errors" was more to full process of creating and then getting the key, instead of only one command. (Not sure if I explained it correctly...sorry, bad english)

Run this:
Then tell me again that there is validation before the get command.
I still don't get it. The "full process of creating and then getting the key" includes "getting the key." It does not validate at that step. In any case, a script may simply use "exist" before "get" when there is doubt, and there won't be a problem.

Last Changes, Version 0.7

• small bug removed ("keys"-command returned an additional unneeded new line)
• bug removed ("deref"-command related): If string contains "@", the string was also divided up into keyname and namespace components.
• small performance improvements
• removed creation of lists for performance reason, for simplefieying and because of some problems, it was not fast as thought because the string had to be parsed. Also the benefit is not much, so no need to slow down other commands.
• Some checks in RegEx for Namespace validation is done. This slows a bit down back.

I think, creation of lists are not fast as I thought/wished. Duo to fact, that parsing of string containing the list is needed.

Source code may irritiate. Its not well documented and there are some dependencies, huge if-structures and multiple Returns.

Here my benchmark results with your script:



Ok I am taking all back. This is a logical think error of mine. I have forgot to check if that requested keyname is in list, before continue with process. Its a bug ... (correcting this should also slow down a little bit later.)

So I should change to check always with RegEx? But you took me to another way to go now. May be in such a function, so many Error checks are not needed??