jump to navigation

On Flex Compiler Warnings August 29, 2007

Posted by khurram in 1084, Adobe, Flex, Flex warnings.
trackback

Some of the Flex compiler warnings are more informational in nature i.e. they are not really warnings just information pointers, sort of like “are you sure this is what you want, if yes then ignore”.  I discuss two of them that directly affect many apps below –

 1.  One such so-called warning comes up when you do not specify an explicit scope for your variable or method.  For example –  

 Declaring a function as follows will give a compiler warning in flex –

public class Foo {

function bar():void {

            //whatever

}

}

The warning would read like this: “1084: function bar will be scoped to the default namespace: Foo.internal and will not be visible outside this package”.  Now this is useful information only if the developer wanted this function to be visible outside its package.  On the other hand, if the intended design was to not have this function visible outside the package, then the signature of the function is correct and specifying any of the scope keywords (public, private or protected) on this function just to get rid of the warning would be incorrect as that’s changing the design.  Package scope is common in modern object oriented languages such as Java and ActionScript 3.  Java compiler does not complain about it, AS compiler shouldn’t too.

2.  The other such warning that comes up very frequently in Flex has to do with bindings.  For example –

 Let’s say that I have a mxml component as follows:

<mx:Text text=”{label}” xmlns….>

            <mx:Script>

                        <![CDATA[

                                    public var label:String;

                        ]]>

            </mx:Script>

</mx:Text>

 Flex will give you a warning that changes to label will not be detected by data binding.  This is an issue only if the developer wants the variable to be bindable.  In many cases in an application where [Bindable] has not been specified for a variable, the developer did not want it to be bindable mostly because the variable will never change its value once it has been initialized or if the intent is that the change in value should not update the bound variable.  One way to achieve this is to manuelly update the value in AS code instead of specifying it as a bound variable in MXML.  That is not the idea case for people like myself who like the elegance of MXML and want to resist the temptation to write AS code.

Advertisements

Comments»

1. darron - August 31, 2007

Both of those warnings are easily fixable.

For the first one, if you explicitly use the “internal” scope the warning goes away. Essentially the compiler telling you that you forgot to include a scope for the method, and letting you know that it picked internal by default.

For the second one, you’re assumption that “the developer didn’t want it to be bindable” is incorrect. If you’re using an expression inside binding, the by definition you want that expression to be bindable. Therefore, it needs to have [Bindable] metadata to trigger updates. If, instead, you use “const” instead of “var”, then you don’t need to tag something as [Bindable] because you’re explicitly telling Flex the value isn’t going to change.

Instead of “public var xx” you can simply turn it into a “public function set xx” and update the value through code, as you already mentioned.

Compiler warnings exist for a reason, usually as check points to say “did you really mean to do this? if so, be explicit in your code”. My personal philosophy is to treat warnings as errors and fix them whenever they come up.

2. Peter Witham - March 11, 2008

I am so glad I found this post, those 1084 warnings were driving me crazy when I had functions in an external AS file that was not a class. And thanks to Darron for the internal tip to make them go away.

3. Eduardo - July 7, 2008

Is possible use a directive compiler with flex to don’t display some type of warning ?

4. Tom - July 10, 2008

I’ve got the same waning regarding ‘internal’ scope, but for variables rather than functions. Adding the internal keyword doesn’t make the compiler warning go away:

var addresses:ArrayCollection;
internal var addresses:ArrayCollection;
protected var addresses:ArrayCollection;

All produce that warning –any suggestions? What am I missing?
Thanks!

5. Andrea - July 22, 2008

Thanks, really useful!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: