Functions | &ByRef • ByVal

Discuss the future of the AutoHotkey language
User avatar
Posts: 4480
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Functions | &ByRef • ByVal

26 Apr 2018, 01:15

I can only repeat what I said before.
Recommends AHK Studio
Posts: 113
Joined: 01 Apr 2017, 07:55

Re: Functions | &ByRef • ByVal

27 Apr 2018, 05:12

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
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).

Code: Select all

obj:=["what", "    when  ", "where"]

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
On the entire language on all of the scripts, on all of the functions, function parameters can't be reused internally, because there is no local scope anymore for that variable name.

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)
Then users can deal with the headaches to their heart's content.

& can be used to simulate pointers on call with num/str get/put. & on definition would be consistent with cpp for references.
Posts: 4479
Joined: 17 Jul 2016, 01:02

Re: Functions | &ByRef • ByVal

29 Apr 2018, 02:30

It seems you didn't get the context from which the quote was taken. And you are arguing (?) against something which wasn't suggested.

Code: Select all

Byref function(param1, param2........................................ param25)
That is not a good suggestion for several reasons already mentioned in the thread. f(byref p*) would be more appropriate imo.
& on definition would be consistent with cpp for references.
Not having & mean byref makes it consistent with pbrush.


Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 2 guests