Scoping Strategies

I just fixed a lurking bug in my code today that was related to ActionScript's scoping rules. The bug wasn't obvious to me when I first wrote it, and took some head-scratching when I fixed it. So I thought I'd post in in case this behavior isn't obvious to anyone else eading this (say, coming from a Java background like I do, where this behavior doesn't exist).

I'll boil it down to a simpler 'puzzler' question:

What do you think this prints out?

            var i:int;
           for (i = 0; i < 2; ++i)
           {
               var blah:Object;
               trace("blah = " + blah);
               blah = i;
           }

Or how about this?

            for (i = 0; i < 2; ++i)
           {
               var blarg:Object = null;
               trace("blarg = " + blarg);
               blarg = i;
           }

(I'll put the answer at the end of this post, so that I don't blow the surprise for anyone wanting to figure it out before proceeding.)

What's going on here is that the scope of these variables (like all variables in ActionScript) is at the level of the function. That's right: even though the variable is declared inside the for() loop, they are scoped to the overall function. There are various implications and consequences that come from this scoping rule, but the specific one we're dealing with here is that that scope is also the place where the variable receives its implicit assignment. So in the case of the first example above, blah is assigned the default value of null just once. When we come around to the variable declaration again, it does not get a second implicit assignment, because it's as if the variable were declared at the top of the function, since that's its scope.

Meanwhile, in the second example, blarg is given an explicit assignment. This means that every time around our for() loop, we assign the value of null to blarg, so that the variable is always initialized to that value at the point where we declare it in the code.

To my Java developer eye, these looked equivalent: an implicit assignment would happen at the same time as an explicit assignment. But now I realize that if you really want a variable to have a specific default value, assign it explicitly or suffer the possible consequences.

Moral of the Story: Always assign a default value to a variable, especially iuf the variable is declared in a loop where you expect it to have some default value.

Addendum: To test this behavior in Java, I tried to write similar code to see the results. It turns out that the code wouldn't even compile; accessing the variable (even to System.out.println() it ) without declaring an initial value for it threw a compiler error. I could swear this type of code used to work, but perhaps they tightened up their variable declaration policy since I used that approach.

Answers:

The first example prints out:

    blah = null

   blah = 0

and the second example prints out:

    blarg = null

   blarg = null

Video: AnimateFilter in Flex 4

AnimateFilter Effect in Flex 4, the next episode in the gripping and suspenseful series CodeDependent, is now available from Adobe TV.

This show covers the new AnimateFilter effect in Flex 4, which allows you to animate properties on Flex filters. You could do this in Flex 3, but it required more custom effects or animations, where you would receive the animation events and manually update the filter properties. Now, you can pass in the filter and the animation properties to AnimateFilter and it automatically animates the filter properties. This is another example of Flex 4 effects being able to target arbitrary objects; in this case, it is changing properties on a filter, not on a component. The demo app also shows the new RepeatBehavior capabilities in Flex 4 effects, which makes it easier to create reversing effects, like we have on the pulsating button in the demo.

Here's the video:

Here is the demo application:

And here is the source code.

Finally, here's where you can find the CodeDependent videos on iTunes.

Enjoy.

Pros and Cons

I just heard that my technical session was accepted at Devoxx, so I thought I'd post my upcoming conference schedule:

Adobe MAX: I (along with others on the Flex team and a host of other knowledgeable people inside and outside of Adobe) will be presenting at MAX this year. I will give a talk on (drum roll please; it's sure to be a big surprise...): Flex 4 Effects! MAX is in Los Angeles from October 4 - 7. Come learn about Flex, Flash, and other cool Adobe developer products.

Devoxx: I, along with my co-author and arch-nemesis Romain Guy, will be presenting a session entitled "Animation Rules!," where we will apply lessons learned from cartoon animation to making better GUIs. There should be some other good talks more specifically about Flex as well. Devoxx is in Antwerp, Belgium from November 16 - 20. It is one of the best geek conferences I've been to, year after year, with good, deep talks about Java, Flex, and whatever else is hot and worth learning about in the programming world today. It is also very cheap at the price. Oh, and the fries and beer are great!

Video: Transform Effects in Flex 4

Flex effects: a transforming experience......

Transform Effects in Flex 4, the next episode in the gripping and suspenseful series CodeDependent, is now available from Adobe TV.

This show covers the new "transform effects" in Flex 4, which allow you to move, rotate, and scale Flex objects (components and graphics objects). Similar effects (Move and Rotate) exist in Flex 3 already, but these effects were completely overhauled in Flex 4 to make it easier to get them to do the right thing.

One of the problems with the previous implementations of Move and Rotate is that they would sometimes clobber each others' results. If you think about it, both effects are affecting the (x,y) location of an object, so if the effects are giving conflicting advice, you may not get what you really wanted. For example, a Rotate effect in Flex 3 would rotate around the center of the object by default, meaning that the (x,y) location of the object would change as it rotated around that center point. Meanwhile, a Move effect on that same object would be giving conflicting advice on how to move that (x,y) point. The results tended to be unpredictable at best.

In Flex 4, we've combined Rotate and Move, along with the new Scale effect (essentially a replacement for the old Zoom effect). Now, instead of separate effects individually setting overlapping properties on the target object, they all combine internally into one single "transform effect" instance and combine their operations into a single transform operation that sets the location, rotation, and scale of the object.

And of course, the effects also benefit, like the other Flex 4 effects, from the ability of the Animate effect to target arbitrary target objects (useful in the world of Flex 4, where we may have graphical objects in our application instead of just UIComponents).

Here's the video:

Here is the demo application:

And here is the source code.

Finally, here's where you can find the CodeDependent videos on iTunes.

My favorite part of the video: I got to use the words "junta" and "cahoots" - how often does that opportunity present itself?

Enjoy.

Video: Fade Effect in Flex 4

Old components never die; they just fade away.

Fade Effect in Flex 4, the next episode in the gripping and suspenseful series CodeDependent, is now available from Adobe TV.

This show is all about the new Fade effect in Flex 4, which allows you to fade objects (components, graphic objects, and anything else with an alpha property) in and out. This effect exists in Flex 3 already, although it got a little reworking in Flex 4 to add useful functionality. For one thing, it uses the ability of the Animate effect to target arbitrary target objects (useful in the world of Flex 4, where we may have graphical objects in our application instead of just UIComponents). But also, the new Fade effect has a little more intelligence built into it that helps it figure out when you want to automatically fade things in and out, based on the value of related properties like visibility and whether the object is becoming parented or unparented between states of a transition.

Here's the video:

Here is the demo application:

And here is the source code.

Finally, here's where you can find the CodeDependent videos on iTunes.

Enjoy.

Video: AnimateColor in Flex 4

AnimateColor in Flex 4, the next episode in the gripping and suspenseful series CodeDependent, is now available from Adobe TV.

This show is a follow-on from the previous show on the Animate Effect in Flex 4, which talked about the superclass of the new effects in Flex 4. This show is all about the new AnimateColor effect, which allows you to animate colors on arbitrary Flex objects using the new type interpolation capabilities in the Flex 4 effects. While we showed how to do this with the Animate effect in the previous video, using AnimateColor is a more natural way to achieve this specific effect. We also talked a bit about AnimateColor in the video Color My World, although that show was more about comparing RGB and HSB colorspace interpolation, and this show is specifically about using the AnimateColor effect. And yes, this is the last show where I talk about color for a while. I promise.

Here's the video:

Here is the demo application:

And here is the source code.

Finally, here's where you can find the video on iTunes.

Enjoy.