- IsNum(Num) would be a shorthand for (Num is "number"). I.e. 'looks numeric'.
- (An extra Options parameter could have various letter options: e.g. looks like a Float (F), looks like an Integer (I), possibly has a specific type.)
- (Generally, I find some 'is' operator types a bit ambiguous, possibly, I might prefer a StrIsType(string, type) function, and a more specific StrIsNum(string) function.)
- Num(Num, Default:=null) would be similar to Float/Integer, but more general.
- Something that looked like a Float would be returned as a Float.
- Something that looked like an Integer, would be returned as an Integer.
- Something that looked non-numeric, would raise an error, or, if the Default value was specified, the Default value would be passed (which could be a string).
- Perhaps something already of Float/Integer type would maintain its type.
- A Num function would convert a string to a Float/Integer as appropriate. Otherwise some possibly verbose check must be done to decide whether to use the Float function or the Integer function.
- The Default parameter could be omitted, you'd do instead:
var := IsNum(var) ? Num(var) : default
var := (var is "number") ? Num(var) : default
- I'd be happy to have these remain as custom functions in my general library, but I thought they'd be potential candidates for being built-in.
- Some code for IsNum and Num that attempts to be AHK v1/v2 compatible.
Code: Select all
;==================================================
;e.g.:
;MsgBox(IsNum(1))
;MsgBox(IsNum("a"))
IsNum(vNum)
{
local
try vTemp := vNum + 0
catch
return 0
return !(vTemp = "")
}
;==================================================
;e.g.:
;MsgBox(Num(1))
;MsgBox(Num("a", 0))
;MsgBox(Num("a"))
;vNum := "a"
;MsgBox(vNum + 0)
;if vNum looks numeric, return it
;if vNum doesn't look numeric, error, unless a default value is specified
Num(vNum, oDefault*) ;vNum, vDefault:=null
{
local
try
{
vTemp := vNum + 0
if !(vTemp = "")
return vNum
}
if oDefault.HasKey(1)
return oDefault.1
throw Exception("Type mismatch.", -1)
}
;==================================================
INT AND STR
- (AHK v2 currently has Integer/Float/String.)
- Perhaps Integer and String should be shortened to Int and Str.
- The shorter names increase readability in long concatenated expressions.
- Int is quite common, Integer seems unnecessarily long.
- AHK already has StrXXX functions.
- Str is used by Python and possibly other languages.
- It's possible that the longer names were chosen to match what Type returns, but I think that this consideration is outweighed by Int being common and Int / Str being more readable/practical.