>>> Re. an array on the left-hand side. Perhaps this, the following two lines would be equivalent:
Code: Select all
vCount := ([a,b] contains [c,d])
vCount := (a contains [c,d]) + (b contains [c,d])
- So if oArrayA contains oArrayB
would be equivalent to 'if at least one of the items in oArrayA contains at least one of the items in oArrayB'.
- One use would be the reverse of 'contains', 'if abcde contains one of abc,def,ghi', versus, 'if abc within one of abcde,fghij,klmno'.
- I didn't especially feel the need for 'if var contains', to become 'if list contains', so I would welcome any other ideas.
- I did feel that 'starts'/'ends' would be useful, like RegExMatch, but faster, and no escape issues.
>>> Re. how to handle a string.
- After reading v2-thoughts, it seems it has to be a comma-separated list, as it is now. I've changed my mind.
- You can do 'if var in [LiteralString]', if you want to treat commas literally. This was something that was not available in AHK v1, this makes the argument for maintaining the 'string as comma-separated list' argument stronger.
- Btw I would remove special handling for ',,'. Furthermore the ',,' syntax wasn't very effective anyway, you couldn't do this for example: ["Run,", "RunWait,"].
- 'if var1 = %var2%' became 'if (var1 = var2)', likewise 'if var1 in %var2%' could become 'if (var1 in var2)' in AutoHotkey v1/v2. With the array handling and removal of special ,, handling.
- If StrMatch functions etc existed, they could treat commas as literal, unless 'D,' was specified, because they have that additional third parameter, hence more flexibility.
>>> Also. Linear arrays v. associative arrays as input.
- A general issue is, when you use arrays in functions, should all keys be read, or just the positive integer keys *including* integer keys in the gaps that aren't assigned. I'm happy with it *always* being the positive integers (and treating keys in the gaps as blank strings), but perhaps there should be exceptions/options. I would like to hear people's opinions on this.
>>> Also. Dynamic operators.
- In some situations relating to string/numeric comparisons, I would like to be able to do something like this: if Operator(var1, var2, "<=")
- Btw basic 'does a equal b' comparisons can be fiddly:
Code: Select all
;can be fiddly
if (a+0 = b+0) ;numeric
if !("" a != b) ;as text, case insensitive/sensitive depending on A_StringCaseSense
if ("" a = b) ;as text, case insensitive
if ("" a == b) ;as text, case sensitive
if StrExact(a, b, "N")
if StrExact(a, b, "T")
if StrExact(a, b, "T CI")
if StrExact(a, b, "T CS")
- There are various examples in the help where an 'exact' match can be case sensitive or case insensitive. E.g. For the "in" operator, an exact match with one of the list items is required.
So I'm happier now about the 'StrExact' name.
- @coffee: Yes,  is good for variables (containing numbers/strings) and hardcoded numbers. StrSplit is good for hardcoded strings.
- @guest3456: There's no reason why things can't be both functions and operators. The traditional 'in'/'contains' operators require character escaping, require force expression, and force splitting if conditions across lines, obscuring the logic, and increasing indentation, and could have done with a function equivalent. E.g. re. obscuring the logic, when I went back replacing 'in'/'contains' in scripts with functions, it was hard to tell when I could/couldn't combine some of those lines with adjacent lines. In my opinion, a Between function would be better than the 'between' operator, and 'is type' might as well have been a function only.