Ariel, Rob,
Neither booleans nor switch statements are suitable in this context, though they may appear more appropriate than the actual generated code at first glance. Please see my above post for the details. Remember that we are trying to generate code that works in the general case, not just this particularly simple case.

While the variable could (and perhaps, *should*) be a const, I think the primary justification would be readability, not performance. Making it clear that we don’t intend to change the value of that variable might help make this code clearer, which is of course a good thing. But this code is not executed often, so any performance benefit derived from using a const would be negligible.

Don’t you get compile errors when you reference an non-existant state in the new state syntax in an MXML tag? The const doesn’t help avoid state name typos in MXML but should help to keep typos in ActionScript from causing problems that are not picked up by the compiler.

-James

private var quarterDesriptions:Array = [ "", "1st Quarter", "2nd Quarter", "3rd Quarter", "4th Quarter" ];

quarterDesription = quarterDesriptions[quarter];

But, when comparing ternary, if/else or switch, I’m wondering how you would set this it up like Python.

-TH

private function getQuarterDescription( quarter:int ):String
{
switch(quarter)
{
case 1:
return “1st”;
case 2:
return “2nd”;
case 3:
return “3rd”;
case 4:
return “4th”;
}

return “”;
}

It would be nice if we could use a single constant for a string name. Typically this is done so that should you ever want to change the value of the string, you need only change it in one place. We would miss out on this benefit because AFAIK you cannot use anything but a literal string in a State tag, and state specific properties are always of the form stateName.propertyName. So even if we were to use constants in the generated Actionscript code, if you wanted to rename a state, you’d still have do something like a search and replace.

- Matt

Perhaps the only thing that Catalyst should change is to use consts for the state names instead of strings. Maybe you could even bind to those consts in the State tags. I remember hearing at one point that there might be some compiler optimizations done when binding to consts. If so it would be nice to not have state names as strings everywhere.

-James

I’m the developer working on interactions in Flash Catalyst. Most programmers, myself included, would probably write something similar to the following to toggle state between “open” and “closed”:

currentState = ( currentState == “closed” ) ? “open” : “closed”;

This code is simple, straightforward, and readable. Let me explain why our generated code ends up being more complex:

(For those of you who have not used Flash Catalyst, a brief explanation: an interaction is just a snippet of Actionscript code that either sets the state of a component or plays an effect. It can have a condition attached that causes it to only execute when a component is in a given state).

Interactions in FC are not mutually exclusive – if I have several interactions that fire when a user clicks a button, any number of them could end up executing. As a result, we can’t just use an if/else block, or our interactions would end up being mutually exclusive.

When only a single component and a single property (currentState in this example) are involved, an if/else block would indeed be the most appropriate structure, but that is a special case. For example, consider the following interactions:

On click, play transition to state1, when in state2.
On click, play transition to fooState in someComponent, when someComponent is in barState.

There are two components involved here: the component you’re editing, and someComponent, a child component. We might be tempted to write these interactions like so:

if (currentState == “state2″) {
currentState = “state1″;
} else if (someComponent.currentState == “barState”) {
someComponent.currentState = “fooState”;
}

But if we wrote that, we’d have a bug: when our component is in state2, we never execute the second interaction, regardless of the state of someComponent. The correct code, for this case, looks like:

if (currentState == “state2″) {
currentState = “state1″;
}
if (someComponent.currentState == “barState”) {
someComponent.currentState = “fooState”;
}

In the general case, we have to use independent if blocks. This makes sense because interactions in FC are fundamentally independent from one another and the code should reflect this.

Now let’s consider your example, where we want to toggle between open and closed states. Knowing that we should use separate if blocks, we might come up with:

if (currentState == “open”) {
currentState = “closed”;
}
if (currentState == “closed”) {
currentState = “open”;
}

Again, we have a bug: if currentState is “open” before this code runs, it will still be “open” after it runs, because both conditions evaluate to true. The problem here is that we’ve written code that assumes the value of the currentState property won’t change until it has finished executing, which is of course a flawed assumption.

Considering that we’ve already determined that if/else doesn’t work in some cases, the general solution is to do what FC does: store the value of currentState before we’ve changed anything and test against this saved value. When an FC user writes interactions, they are probably not considering that the value of their condition might change part way through the handling of a single event. The generated code is probably not what a programmer would write, but it most accurately reflects the intentions of the FC user.

Certainly in this example, this code looks silly. In the general case, however, using the extra variable is necessary. I decided that it was best to keep our code generation consistent, even if that means making the simple cases look slightly more complex than they actually are.

- Matt

(not to discount David’s ideas…but those are the same ones that I had…Adams idea was totally new to me)