the kicker is that no one has really focused on what sort of variable is involved
which is the basis for what “BYREF” is even going to affect
a VALUE type passed BYVAL gets a COPY of the VALUE - you cant change the original VALUE
a REFERENCE type passed BYVAL gets a copy of the REFERENCE - you cant change the original REFERENCE - but you CAN change the properties of the thing it refers to ! This is obvious when you pass an instance of a class. Of course you can change that instances properties
Now pass byref
a VALUE type passed BYREF gets a REFERENCE to the VALUE - you CAN change the original VALUE
a REFERENCE type passed BYREF gets a REFERENCE to the REFERENCE - you can chnage the original REFERENCE
its pretty simple
but you have to talk about the what sort of variable it is (value or reference) to be able to talk about byref properly
And ARRAYS are a REFERENCE type
you can, usually, nil reference types
strings are actually reference types BUT implemented in a way thats totally invisible inside Xojo itself
but not in a plugin
Arrays though you CAN nil and the fact they are references types is discernible in Xojo
dim a() as integerdim b() as integer
if a is b then
break
end if
a = b
if a is b then
break
end if
I understand this, but I also understand why it is confusing. Without exposure to C and machine language, I don’t think it’s obvious why a value type is different than a reference type.
var width, height as integer
var dimensions as size
Why are width and height value types and dimensions a reference type? Why wouldn’t they all be value types? Or all reference types? This distinction must seem kind of mysterious and arbitrary if how it actually works in memory is hidden from you. Knowing they are different types doesn’t really explain why, so it’s hard to get intuition about it. And it doesn’t help that the page on ByRef only mentions arrays in the context of it not being supported on Android.
dim a() as integer
a.append 1
break
fooByVal(a)
break
fooByRef(a)
break
sub fooByVal (anarray() as integer)
dim b() as integer
b.append 456
anarray = b
break
end sub
sub fooByRef (byref anarray() as integer)
dim b() as integer
b.append 456
anarray = b
break
end sub
the code above produces the following in the debugger
anarray (the original A() passed in is altered to now refer to the same array as B)
and has an ID of C970BA0609505C061 (NOT the same as it was originally)
We have exited the method and VOILA !!! The change we made in the method to make A() refer to a different array has been retained ! It still refers to the array with ID 6933BB0609505C06
the trick is what sort of variable is passed in - a VALUE type or a REFERENCE type
Arrays are reference types so BYREF means you get a reference to a reference and you CAN change what the reference refers to
i don’t know about that. i think everyone who learned any compiled language was exposed to this concept, at some point, since it’s implemented in so many languages, including those that predate c.
in fact, i can think of several modern, interpreted-only languages that have passing by value or by reference, as well. of course the vocabulary and the symbols that languages choose has much to do with how easy a topic is to grasp - in this case we could just as easily say that we are passing the original or passing a copy. then, somewhere, several paragraphs later, we could either explain all the detail or reference materials that discuss it.
people confuse “passing a copy” with “a copy of the DATA” but thats not correct and often you see people think they can pass an array into a method, modify it, and the original from the caller is untouched
And are surprised when thats NOT the case
It all comes back to knowing the difference between value & reference types
Right
But thats NOT illegal in Xojo because the passed in parameter is effectively a local variable so you can assign to it
The only difference is whether or not any local changes are, or are not, passed back to the caller
I was’t trying to say Swift was more or less right than Xojo …. unlike those that insist Java is more right than everything…. My point was to show how it was different
Atb the end I said also: For Apple and iOS I would, if the app has not to be cross platform, always use Swift/Swift UI. Why? While this would be the best method. But unlike you I am not programming for the apple world alone so I need to… And yes, looking from Xojo: it is much better.
i’m so old that i don’t even think intentwas part of the language when i learned it.
did fortran ever add reserved words? if you’re not familar, at least when i learned it, fortran keywords weren’t reserved, so you could use them as variables, too. if i remember it,
