I see there are lot of answers, but I will reply before reading them...
I went for NumGet / NumPut because:
- Extract and even more Insert seems inappropriate. We don't insert
a number in a buffer, we write it, and overwrite the existing value: no shift of data.
- The encode / decode pair is too technical and not even correct for me.
OK, now to read the other opinions... :-)
[EDIT 1] I have read Chris' message, and I don't agree...
GetNum(VarOrAddress, Offset = 0, SignedOrFloat? = 0, Size = 4)
PutNum(Number, VarOrAddress, Offset = 0, Size = 4) ; Best parameter order?
For GetNum, I would put the size before the SignedOrFloat? flag: we have to specify a size more often than to use a signed number.
For PutNum, I would put the VarOrAddress param first, for consistency.
The whole reason to support raw addresses instead of simply address-of-variables is flexibility: it seems conceivable the caller may have a raw address from somewhere but not know which variable it points into.
I can't think a single case where a user can put an hard-coded numerical address...
And if a DllCall returns a memory address (I do a GlobalAlloc, then a GlobalLock call to get the address of the buffer in my SetClipboardData function), how do we use it? Can we write PutNum(%pMem%, ...) for example?
Come to think of it, there is a pair of names you didn't provided: GetNum / SetNum. Set seems like a more natural companion to Get, at least for those used to setters and getters, eg. in Java.
[EDIT 2] I see Sean
agrees with me on Get/Set... :-)
So it would be:
NumGet(Address, Type = "UInt")
NumPut(Address, Number, Type = "UInt")
Looks good, except for the names. ;-)
Exception handler: I have seen that using that in a program bloats it a lot, but it is used in DllCall already, so the evil is already done... :-)
And indeed, I believe a scripting language should catch as much errors as it can, even if it reduces performance, that's the price of ease of use.
Note that I can crash my scripts already, with some bad DllCalls. Once, it was because I forgot a comma between the type and the value: "UInt" var. It took me a long time to understand where the error was... Another evil side effect of implicit concatenation, hiding a syntax error.