The Problem:

When using the square bracket notation to de-reference a property of an object within the mxml, you receive an invalid warning as in the following example. It stops you from noticing warnings that actually mean something, I’ll call it “warning blindness.”

First seeing these warnings a developer might think they need to add the [Bindable] tag to the object. Doing so will eliminate one of the errors, but will add to the compilation time and won’t really add any value unless the value of the object changes and it needs to actually dispatch events for binding updates. Furthermore, the developer would still have the warning regarding not using the square bracket operators within a binding tag. If the user wants to receive binding updates or is less concerned about the extra overhead added by using the [Bindable] tag they may do so. This is a useful warning; it informs you of something that will actually make a difference come run time. The other warning is not taking into account the context of the square brackets, and falsely “believes” that the type of the variable using the square brackets is an Array or an ArrayCollection rather than an object, and is thus informing you of your possible error. This isn’t a problem if you have 1 or 2 of these, but say you have 30. Now it starts to clog up your warnings box and you start ignoring (or not seeing) things that actually matter. This is especially a problem in Flex Builder because warnings tend to not clear properly when doing an incremental build, so many times it will replicate the warnings (clean build in my experience has always worked to clear the warnings and give me the proper list, but clean building means building things that didn’t change and therefore wasted compilation time).

The Solution:

Since the function call in the binding only references the object changes to the underlying properties it will not cause the bound value to be updated, rather the entire object must change as in the following example:

If this is an issue across an entire application, the method can easily be plugged into a static utility class and used throughout the application. Also be mindful in the above example the curly braces in the click event of the button signify a new object not a binding.

package utils
{
public class ObPropUtil
{
public static function obProp(object:Object, prop:String):Object
{
return object[prop];
}
}
}

And then easily used anywhere with ObPropUtil.obProp(someObject, SOME_PROPERTY) in place of someObject[SOME_PROPERTY]

If you aren’t using constants, you can generally chain along the dot operator without a problem (you cannot use constants in place of a literal variable using the dot operator chaining, and therefore are forced into using the square bracket operator).