@Flipeador: Yes, I had been thinking about this too, it would be a good idea. I often use the address for DllCall and in custom functions that I've written, and I find NumGet/NumPut as they are now inelegant and awkward to use, even a potential source of bugs. This is the sort of change that is consistent with AHK v2, and the sort of big change that should ideally only occur during a major update.
The con(s) would be all the conversion of NumGet and NumPut. I'm quite relaxed about changes made to commands, because I will convert all of them to functions, and there is no chance of confusion. I am always more reluctant to change the definition of functions because of the possibility for confusion. However my instinct says to make the change.
If someone had a lot of AHK v1 code, and they wanted to quickly convert it to work in AHK v2 (assuming these changes were made), then perhaps these functions would make it possible:
Code: Select all
;unofficial proposal for changes to NumGet and NumPut
;possible AHK v1 functions for AHK v2 proposal:
NumGet1(ByRef VarOrAddress, Offset:=0, Type:="UPtr")
{
if IsByRef(VarOrAddress)
VarOrAddress := &VarOrAddress
return NumGet(VarOrAddress+Offset, Type)
}
NumPut1(Number, ByRef VarOrAddress, Offset:=0, Type:="UPtr")
{
if IsByRef(VarOrAddress)
VarOrAddress := &VarOrAddress
NumPut(Number, VarOrAddress+Offset, Type)
}
Contrariwise I would welcome a directive in AHK v1 to allow you to use NumGet and NumPut as you would in AHK v2 (if this became the new behaviour). [EDIT:] It would be one directive that for all lines between when it is set on and off, applicable functions behave like they do in AHK v2, or, for more granular control, only specified functions in a space-separated list would work like in AHK v2.
Here are functions for that would give you the proposed behaviour right now in AHK v1 and in AHK v2.
Code: Select all
;possible AHK v2 proposal functions for AHK v1:
NumGet2(Address, Type:="UPtr")
{
return NumGet(Address+0, Offset, Type)
}
NumPut2(Number, Address, Type:="UPtr")
{
NumPut(Number, Address+0, Offset, Type)
}
Helgef wrote:This feature is a perfect example of good intentions going wrong.
Yes I have felt that a lot when going over AHK, thinking about changes, the rationale is good, but over time you work out what the better approach is.
@Flipeador: Is that true about UInt64, I had thought that it was implemented but that it acts like Int64, which is fine for writing to structs, but which would affect reading. The issue being that AHK can only handle numbers of a certain size. I don't know the exact details.