Functions: Passing arguments by value or by reference
By chance I just stumbled upon this article from the Livedocs about the way functions interpret the values of their parameters in Actionscript3.
Since I found I couldn’t put it any better than the LiveDocs did, here’s a quote:
In ActionScript 3.0, all arguments are passed by reference because all values are stored as objects. However, objects that belong to the primitive data types, which includes Boolean, Number, int, uint, and String, have special operators that make them behave as if they were passed by value.
Passing arguments by value or by reference (Adobe Flex LiveDocs)
Read the whole section on passing arguments for a better and more thorough description on the whole concept.
June 3rd, 2007 | Quote
Alright, actually that was more or less what I meant, I merely put it the wrong way.. Thanks alot for going through the trouble of explaining all of it man..
June 3rd, 2007 | Quote
No, being immutable means that you can’t change it at all.
Remember that there is a difference between a variable and an object. A variable is just a named reference to an object, changing the variable just points it to another object (that is what = does, it changes where a variable points).
You can have two variables referencing the same object. Lets say we have “foo” and “bar” both pointing to the same array:
var foo = [1, 2, 3];
var bar = foo;
Now, if you change the array using the foo variable, that change can be seen by inspecting the bar variable too:
foo.pop();
trace(foo.length); // prints 2
trace(bar.length); // prints 2
However, if we do a similar excercise with ints it it doesn’t work the same way:
var foo = 5;
var bar = foo;
foo += 3;
trace(foo); // prints 8
trace(bar); // prints 5
This is because there is no way to change the object that was referenced by both foo and bar, if you want something else (like foo + 3) you will get a completely new object.
There are methods on Array that returns new objects, for example concat and slice, so not all operations are equal:
var foo = [1, 2, 3];
var bar = foo;
foo = foo.concat([4, 5]);
trace(foo.length); // prints 5
trace(bar.length); // print 3
What happened in this last example is that the foo variable got overwritten by a new array (the return value of the concat call), but bar still pointed at the old array.
June 3rd, 2007 | Quote
So a type being immutable basically means that its value can only be changed by using the = operator..
Knowing this, it indeed makes a bit more sense why simple types behave as being values instead of references..
I really appreciate that you took the time to post that, so many thanks for the explanation!
June 2nd, 2007 | Quote
Take the example of Array vs. String: arrays are mutable, i.e have methods that change the same instance as they operate on (push, pop, shift, unshift, for example). Strings are immutable, however, it has no methods that change the instance they operate on, only methods that return a new string. The same applies to int, Number and Boolean.
If you pass an array to a method and that method changes the array (by calling pop, for example), you can determine if the array was passed by reference or by value depending on whether or not the array was changed in both scopes, or just in the called method’s scope.
If you instead pass a string to a method it doesn’t matter whether that string is passed by value or by reference, because there is nothing you can do to prove that it was passed one way or the other. You cannot change the instance, so every copy of the instance will be equal.
June 1st, 2007 | Quote
Hey Theo, thanks for the feedback, would you care to explain what exactly you meant with what you said?
June 1st, 2007 | Quote
On the other hand, primitives are immutable, so you would never know the difference either way.