Flash Builder 4 inline syntax for states looks slick but encourages bad behavior

I’ve been gearing up to dive into Flash Builder 4 and have read a couple of articles  about its new features.  One that caught my attention was a new, inline syntax for referring to states, e.g., <s:Button label.A="Button" label.B="State B" includeIn="A,B" />, to switch the label for the button depending on the current state (A or B).  As Jon Rose explains it:

The legacy state syntax in Flex 3 required components and properties to be modified within the state block. This was out-of-context, often verbose, and frequently confusing. Flex 4 introduces a new inline syntax that is both flexible and terse.

Not to single out Jon, because I saw it in other articles as well, but it points to a lack of understanding of one of the strengths of a state-based approach: all the code for a state is contained in the same location, and hence it is much easier for the developer to understand what the application does in that state.  The new, inline syntax for states allows developers to sprinkle behavior related to different states on the same element, which means if one wants to understand the overall behavior of a state, one has to examine all the potential elements.

I was particularly struck by Jon’s comment that because “Flex 3 required components and properties to be modified within the state block”, it was “out-of-context” and “frequently confusing”.  That sounds strange to me, because requiring changes to be enclosed in the state block actually is the correct context, namely things that happen in that state, where one looks for information about how that state behaves!

Admittedly, I have not really worked in Flex 3 or Flex 4 (yet), but I believe the concept of states should transcend the development platform.  Therefore, I have to give a ‘thumbs down’ to this new inline syntax for states.