For those of you that may not be aware... if you use properties in your ActionScript 2 classes there is an implicit call to the get method whenever set is invoked. I believe Peter Hall was the first to point this out, and Robin Debreuil mentioned it on FlashCoders as well. I wanted to give this behavior a little more publicity, so I'm bringing it up again. Near the end of this entry, I also offer a way to avoid this behavior by manipulating some bytecode.
This behavior can be a bit of a headache if you don't realize that it is happening behind the scenes, especially if you're doing something in your get function other than simply returning a value.... which leads us to wonder why this even happens in the first place. If I set a property, why does the get method fire at all? In other languages that implement properties (C#, for example), there is no implicit get invocation, so it appears that this is just another "Flash quirk." We'll need to dig into the bytecode to figure out what Flash is actually doing...
Here we go! (Read on)
Below is a simple class "Cow" that demonstrates using properties in ActionScript 2. There is a private string variable "_moo" in this class that has a corresponding public property "moo" used to set and get the value of "_moo." By forcing access to our private variable through the public property, we can validate our data (to keep the class instances in a consistent state) and still give the users of our class an easy way to manipulate our object. This is just like getter/setter methods, except that the public property behaves just like a regular variable would, and a method doesn't need to be explicitly invoked to get or set values.
class Cow {
private var _moo : String;
public function get moo() : String {
trace("get called");
return _moo;
}
public function set moo(value : String) : Void {
trace("set called");
if (value.length == 0) {
throw new Error("cannot set moo to a zero-length string");
}
_moo = value;
}
public function makeSomeNoise() : Void {
trace(_moo);
}
}
(Note: Using "Cow" as a class is courtesy of Jesse Warden)
We can use this class in a new Flash document, like this:
var cow:Cow = new Cow();
cow.moo = "m-to-tha-izzooo";
cow.makeSomeNoise();
// the output windows traces the following:
// set called
// get called
// m-to-tha-izzooo
The above code uses the public property "moo" to set the value of the private variable "_moo," in the same way that a normal variable is set. Behind the scenes, the "set" method is called, setting the private variable to "m-to-tha-izzooo," but first making sure its value is not zero-length String. In a language like Java, that line of code would be replaced with "cow.setMoo("m-to-tha-izzooo");" to achieve the same effect. Using properties is generally more readable than using getter/setter methods to control private variables, as code tends to be smaller but just as (if not, more) intuitive. Of course, in ActionScript either way works just as well, it's just a matter of preference - and I prefer properties.
Anyway, how about that bytecode? It's helpful to see what is actually happening behind the scenes that is causing get to be executed when only set should be. To view the bytecode of your .swf movie, check out Flasm. Below is a portion of the bytecode for the resulting .swf using the above code. I've focused in on the set aspect of the moo property.
setMember
push r:2, '__set__moo'
function2 (r:2='value') (r:1='this')
push 'set called'
trace
push r:value, 'length'
getMember
push 0.0
equals
not
branchIfTrue label1
push 'cannot set moo to a zero-length string', 1, 'Error'
new
throw
label1:
push r:this, '_moo', r:value
setMember
push 0.0, r:this, '__get__moo' // <-- hmm, why is this here?
callMethod // <-- and here is where the get is actually called
return
pop
end // of function
You can see that after the "_moo" value is set, the bytecode instructs the player to call "get" on the "moo" property before returning from the function. I'm not entirely sure why that bytecode is added there in the first place.. but if we delete those two lines, and then assemble the .flm file with Flasm (flasm -a myMovie.flm), everything seems to work without set calling get anymore. I haven't tested this thoroughly so I wouldn't recommend using it blindly. Please do your own testing as well to make sure your movie doesn't break..
Does anyone know why those 2 extra lines are added in the bytecode to begin with? I'd feel better about deleting them if I knew they weren't in use, but I have this feeling that Macromedia has them in there for a reason... Either that, or it's just something they missed in compiling ActionScript 2.
Thoughts, or comments?
5 Comments
Setters should return a value (though you can't do it manually, Flash asserts it by calling the getter implicitly). This is because there might be chain assignments like a=b=c=5, when you think about any variable there not as a simple variable but a function, you see the need.
Now, why don't setters simply return the value passed to them and they return the value they get from the getter? This assures you get the value really set. I really don't see the need too, I'd say that's just a convention, we need to be aware of.
Posted by: Burak KALAYCI | November 19, 2003 10:54 PM
Thanks Burak for that explanation, but...
If I say:
a = cow.moo = "m-to-tha-izzooo";
"a" is not set to anything after removing the 2 get lines from the set method. So, I see your point - it only makes a difference if the property is uised in chain assignments.
However, in C#, whenever you have a property that modifies the value it's being set to, the original value is still passed-through on chain assignments. It passes theough the value without calling get. I would expect Flash to work the same way, but it doesn't. Anytime I chain assignments I expect that all of the variables will be set to the right-most expression. If I wanted different behavior (i.e. a to be set to cow.moo, not "m-to-tha-izzoo"), I would break the assignment up into 2 lines.
Because of that, I can't see any reason to have the get being called at all. The right-most expression should be used in all assignments, not the value returned by get. But, this isn't the first time different languages treated the same things differently.
Posted by: darron | November 20, 2003 7:59 AM
THANK YOU! I was racking out my brains as to why my code seemed to be ending before it was done. I'm glad you guys are out there. I'm gonna keep a close eye on this site now! ;)
Posted by: Julian Calzada | June 3, 2004 1:28 PM
Missed this post the first time around, but seeing it now - I can see one reason to explicitly have the get called. Imagine this scenario:
class Dude {
private var _Name:String;
public function get Name():String { return _Name; }
public function set Name( name:String )
{
if( name != "" )
{ _Name = name; }
}
}
// example usage:
var myDude:Dude = new Dude( "Jack" ); // _Name set to Jack in cTor, not shown above
var a:String = myDude.Name = "";
trace( a ); // traces 'Jack'
In this case, if Flash simply returned the value parameter that had been passed in, your application would erroneously trace an empty string.
Contrary to your comments above, I'm not sure why an assignment statement should always return the right most value. I would think it should act the same way as:
myDude.Name = "";
var a:String = myDude.Name;
After pondering this it's really a question of the intent, and how the language handles it.
Take an example that even goes a step further (skipping the class declaration):
private var _Nickname:String;
public function get Nickame() { return _Nickname; }
public function set Nickname( nick:String )
{
_Nickname = "The Dude " + nick.toUpperCase() + "!";
}
Again, the same question - what is the intent of the assignment - do I want to explicitly assign to the value I pass to the __set_Nickname function (considering that's really what's happening)? Or do I would to chain the assignment, such that everything to the left of the value gets assigned that value.
As usual, the posts are exemplary, Darron.
Posted by: Jason Nussbaum | March 2, 2005 6:49 PM
This "set calls get" bug(functionality?) had me going for awhile when I was designing a fast access hash tree for my Flash app. I thought my experiment had gon wrong somewhere! I decided to stop using properties after I finally found my problem was only a result of this strange get/set plurality. Nice post.
Posted by: Daniel Chay | September 29, 2005 3:43 PM