Functions | &ByRef • ByVal

[nnnik]

I can only repeat what I said before.

[coffee]

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"]
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

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.

[Helgef]

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.

Cheers.