Property getter/setters in MX2004 and the Component Inspector

Properties in MX2004 highlight how Flash uniquely occupies a space somewhere in between the Windows centric world and the Java centric world.

In Windows style a property is used just like a variable
var x = myComp.myCustomProperty;
myComp.myCustomProperty=x

and are declared using the get/set keywords

function get myCustomProperty():Number{ return __myCustomProperty; }

However in the Java world we use get/set methods
var x = myComp.getMyCustomProperty();
myComp.setMyCustomProperty(x);

and declared like this
function getMyCustomProperty():Number{ return __myCustomProperty; }

So what's the big deal you ask, so Flash just lets you use either style, so isn't that a good thing?

Well, yes if it did in fact let you freely use both styles, but it doesn't!

You see if you want to expose that property in the Component Inspector you can only do that using the implicit get/set style but on the other hand if you want to define your property in an interface you can only do that using the getter/setter methods.

So that's a problem. You can't create a property that works in both the Inspector and an Interface.

So how can we work around it? If you look at the MM Source Code you will find the only answer is to simply code both style of property getter/setters.

At a minimum this is inefficient coding, adds to the bloat of components and is more code to debug.

I hope this will be resolved in the next version of Flash, preferably by making the Java style getter/setters work with the ComponentInspector or by allowing properties in interface definitions.


Whilst talking about the ComponentInspector, I must say this is something that really needs improving a lot in the next version of Flash.

In MX2004 it can be said to be a good first effort but it is still years behind component inspectors common in other products.

Features I would like to see are:
1) Custom Property Editors - Create a property editor using JSFL and assign that editor as a handler for particular properties of a component. Currently you can have a component wizard but that is a poor alternative. Users expect to be able to click a property to edit it not search somewhere else for a wizard.

2) Custom Class properties - The Collection property introduced a custom class property but only in the context of a collection, we need the same thing but for single properties. Currently you can have an "Object" property but this is very limited, has many inherent limitations and only produces a generic object not a typed class. It also needs to allow this class property to be null.

3) More efficient code generation - Currently Flash generates setter code for all exposed variable, it also requires you to set a default value in the metadata. If a property is still at its default value Flash still generates code to "set" its value. Code that commonly duplicates you own component internal code that sets the default value. The IDE should be smart enough to NOT generate code if a property is using its default value. This is particularly an issue as the IDE generates the code per instance whereas your own internal code is per class. If you have many properties at there default value this can result in a sizable proportion of the movie footprint be taken up by unnecessary code. The current approach only works as long as you only expose a few properties in the IDE (as MM do) but then what's the point of the inspector if you are not going to use it.
It becomes a major issue if you say expose 20/30 properties per component and have maybe 100+ component in an application, that�s an awfull lot of "dead" code being injected into you movie.

4) Allow null values - Currently properties MUST have a value, there isn't a way to have a null value. This is particularly relevant to Object type properties where you currently you need a second Boolean property to indicate "nullness".

5) Improve code generation for Collection properties - Collections properties generate a lot of code, that�s particularly an issue as the IDE generates the code even if the collection is empty. Again the IDE code is per instance whereas your own code is per class which makes collection properties currently impracticable for general use limiting them to special cases and only in components that will only have a few instances per application.


I know this probably isn't the most popular improvement and many may not see the reason why we rate it so highly, but what we are looking to do is to enable you to work more efficiently through providing you with components that are both easier to use and more powerful, in other words a strong foundation will enable you to build better applications.

We believe strongly that a good powerful visual editor is the key to making Flash more usuable as a development enviroment rather than just a "nice" add on. Its also why we prefer to see the IDE improve than resort to third party tools.