Functions | &ByRef • ByVal
Re: Functions | &ByRef • ByVal
No, not similarly. Byref also allows you to wipe out the external object reference by blanking the internal variable and then you have no object outside of the function. There is a world of difference in passing a variable holding a reference to an object by value vs passing it by reference. Object access is explicit, there's no "oops I didn't know I was accessing this object", variables being erasable outside of scope with no indication for it is not (duh).Helgef wrote: Similarily, passing an object to a function, byref or not, allows the function to modify the object, I do not see too much confusion about it
Code: Select all
obj:=["what", " when ", "where"]
msgbox(function(obj))
function(param) ; assume byref default everywhere
{
param:=Trim(param[2]) . " are you coming back?" ; external "obj" is gone
; some other code
; some other code
; some other code
return param
}
msgbox(isobject(obj)) ; nope
One of the strongest points of functions is scope. Byref by default is a low blow to variable scope. It's not a matter of documentation, it is simply not maintainable, not industry standard, bad practice. It's probably worse than declaring globals everywhere where you have an explicit declaration of what the scope is.
Just to show how niche this is, when you pass an object in java to a method, you are passing the reference to the object by value. i.e a copy of it, screwing around inside the method with the variable holding the reference (assigning something else to it) will not ruin your reference outside of it. Primitives are passed by value. The most OOP of all OOP that throws object references around until you puke memory addresses, does not even use what this thread suggests... for autohotkey. And neither does PHP and Javascript. Do you think it's about expertise?
The two main points are, "can't code golf function declarations with a truckload of byrefs" and "the microseconds are gone in my 1 million string iteration synthetic benchmark". I don't think these should be reasons to make autohotkey assbackwards.
I think the most immediate solution for a function wide switch, if any, is what jeeswg suggested
Code: Select all
Byref function(param1, param2........................................ param25)
& can be used to simulate pointers on call with num/str get/put. & on definition would be consistent with cpp for references.
Re: Functions | &ByRef • ByVal
It seems you didn't get the context from which the quote was taken. And you are arguing (?) against something which wasn't suggested.
That is not a good suggestion for several reasons already mentioned in the thread. f(byref p*) would be more appropriate imo.
Cheers.
Code: Select all
Byref function(param1, param2........................................ param25)
Not having & mean byref makes it consistent with pbrush.& on definition would be consistent with cpp for references.
Cheers.
Return to “AutoHotkey Development”
Who is online
Users browsing this forum: No registered users and 43 guests