So keep them coming may be then more people will pay attention to those and Adobe eventually will pay attention too.

There are few other problems that bug me from time to time… Biggest I think is Event model flaws. No event model is way better then AS2 and way closer to proper event models but EventDispatcher seriously lacks methods like getEventListenersNum, getEventListenerAt, removeEventListenerAt, ClearEventListeners… I think I can write my own EventDispatcher class that will include those but that will not solve problems I am having sometimes for all classes that inherit original EventDispatcher

And those include such cases like having memory leaks because of strong linked event listeners and that some objects don’t have links to them in your program anymore but stay somewhere there and still catching events and eating processor time and memory…

Or other problem is that EventDispatcher does not check for duplicates or something and I need to make my own flags in objects and track their state to see if some kind of events listeners already registered or not…

And yet another big lack is operator overloading I stumble on need for it pretty often and may be it is not “must” thing but in combo with no proper code hints in some editors it becomes a true hell Also making static class member functions to simulate constructor overloading is messy sometiems too

And you’re right, hoisting was introduced by the ECMAScript group for compatibility. And before the ES4 split, it was a huge priority for Adobe and AS3 to stay as language compliant as possible. Not sure if you’ve followed the Harmony proposal from the ECMAScript group, but it’s a far cry from ES4 and the current incarnation of ActionScript. Really, they look almost nothing alike and the chances of us being compatible look slim right now.

I can’t speak on the future of AS3 because really, I don’t know where it’s going and I’m not sure Adobe does either. But at this point, I’d like to see us break from ECMAScript. All languages have their problems, but AS3 seems to have complexity issues inherited from ECMAScript that don’t help the people using the language. To name a few, the lack of abstract classes and private constructors has led to countless complaints. And the addition structures like namespaces have just led to confusion.

Regardless of what happens, the future will be interesting.

I believe AS3 hoists variables to be compatible with ECMAScript, and ECMAScript hoists variables to be compatible with JavaScript 1.5. When I was at Adobe, getting 100% ECMA compliance was a major goal. Not sure if things have changed since I left.

As for the language construct, I am not sure exactly how variable hoisting got introduced in JS1.5, but my guess is that ease of implementation was the big reason there. The ES4 discussion lists seem to indicate that most people there don’t like the hoisting behavior.

For my money, the Flex compiler should probably retain the behavior in the compiler, but warn about referencing hoisted variables before they are declared. As for FB behavior, I agree with your assessment that no one does this on purpose so there’s no need to support it.

Hope all is well w/you.

Flex Builder should issue a warning, but it’s part of the language so it’s a fine line. The Flex compiler currently doesn’t track this as an error (even though I think it should), and the compiler is what we use to issue warnings to the user.

You should file a bug with us to get it on our radar.
http://bugs.adobe.com/flex
-David

I just updated the code to initialize myFlag to false before it’s declared. And it will compile just fine, and in my tests it will print “null What am I?”

Thanks for the catch!
-David

IMHO, FlexBuilder should at minimum issue a warning when this occurs as it is most likely a coding mistake, and have the option of forcing an error during compilation to require correction.

function myASFunction():void {
trace(‘myFlag = ‘ + myFlag); // is false
if(myFlag) { //defined way below from a different scope
myMessage += “What am I?”;
trace(myMessage); //will print What am I? // no it wont
}
var myFlag:Boolean;
trace(‘myFlag = ‘ + myFlag); // is false
var myMessage:String = “WTF?”;
trace(‘myMessage = ‘ + myMessage); // will print ‘myMessage’;
}
myASFunction();