Update 2010-02-17: Many thanks to James Ward for sending me the pointers to a couple of Jira Issues in the Adobe Bug and Issue Management System that cover the points below. I have added the links to these issues.
As a Java developer, who worked for more than a year with Flex I suffered from a couple of pain points - features that I am missing badly in Action Script 3.0. Here is my personal list of things that I wish Adobe would incorporate into Action Script 4.0:
#1: Abstract Classes with Abstract Methods (ASL-18)
Well, do I have to have to say something about that wish? Basically abstract classes are such an essential thing, I am still wondering how Action Script made it to 3.0 without them. Just documenting which Methods must be overridden is not enough. And the known workarounds are really... well... hm... forget it - this is a compiler thing, which cannot be checked at runtime.
#2: Generics (FP-811)
The Vector class is a good start - but it's not well supported in Flex 3 (keyword: data binding) and it's not a generic concept. There should be something like Generics in Java that provide type checking at compile time, but can also be used for any custom class, just like in Java.
#3: Threads (ASL-23)
Not every method can be split up into chunks and processed using callLater. Real threads or at least a simplified form are essential for enterprise grade applications. But that's probably the oldest discussion around Action Script which will never be implemented.
#4: Enums
Well, although Enums can be easily simulated using classes, it's way more complicated when working with BlazeDS. When the backend relies on Enums in its data structures all enums must be wrapped in Java Pojos, before Blaze DS can handle them. And worse, even all the data structures that have references to enums, must be wrapped to reference the Enum wrapper classes instead.
#5: Non-public Constructors (ASC-2583)
Makes a singleton in Action Script much easier. Also a protected constructor would enforce the need to sub class a template base class.
#6: Ability to Catch All Errors
That was on my original list, but luckily there is a silver lining on the horizon.
#7: Operator Overloading (ASL-10)
Still missing it in Java and this is, where Action Script could actually beat Java. I don't want to have another equals method for comparing arbitrary classes for equality - I want to be able to simply override the == operator to be able to compare any two objects for equality. Or the + operator for concatenating two data structures. Just like in C++ or smalltalk.
#8: Method Overloading (ASL-9)
While ActionScript provides an easy way to simplify methods with long parameter lists using default values for parameters it's not enough to justify not having method overloading. I do not want to have to write methods like doSomethingWithString(value:String), doSomethingWithInt(value:int), doSomethingWithObjectA(value:ObjectA),...
#9: A True Hash Map Implementation
A HashMap is an essential data structure today. But currently it's hardly possible to implement a true HashMap for all generic ActionScript classes, as the base Object class, does not provide a template method that returns a hash code and therefore no instance can provide a hash code. Another problem is the ability to check for equality - see #7.
#10: Native Widget Style for AIR
According to Adobe, AIR should take over the desktop with local applications. However AIR applications will always look like alien applications, as the look and feel will never match the look and feel of the operating system. If Adobe wants to be taken serious on the Desktop, a native and accelerated Widget Style is a must. This could be done by providing wrappers for the basic components that are displayed using native UI elements (Cocoa, GTK, Windows) and by providing access to the operating systems color scheme.
Well, that is just my personal wish list. Most probably other Action Script developers have much better ideas or would prioritize my list in a different order. I would like to hear your ideas. Be creative and leave comment.
#9: Check out Dictionary; she supports custom types as the key.
#7: well with Method overriding I mean something different. For example have methods defined with the same name and amount of parameters, but different types. The compiler then chooses the method that fits the type of the parameter, when called.
#9: Dictionary is very different. Yes, it supports every type as key, but checks the types for identity, not equality. That is a huge limitation.
1. Lacking a modular design
2. Bloated classes
3. Slow redraw/render
4. Favors inheritance over composition
5. Speed
6. Compiled CSS vs dynamically loaded StyleSheets
7. Favors sloppy coding by mixing view and business logic in MXML
8. An empty swf with Flex is over 150k vs 1k for AS3
9. Most flex sites look exactly the same due to limited skinning
10. horribly confusing marketing by to Adobe when it comes to Flex being a framework and ActionScript is the language.
As far as the points that you raised above, all of them are spot on and need to be added to AS 3!
thank you for your comment. You are right and my intention was to complain rather about ActionScript and not Flex, but I got the headline wrong. I've changed that.
With regards to 8: That happens in case you compile against the framework libraries statically. Use caching RSLs and you will get an SWF that's not much bigger than 1K.
Other than that: Good points!
ActionScript is too over the top for what it does, I propose we switch Flash to use JavaScript
http://thebackbutton.com/blog/93/flash-11-should-be-a-switch-to-javascript/
Why surround-yourself with all these rules?
You still didn't say why you need all these features. What are you being blocked on with these missing features?
I say less in more, Adobe should only be adding features if people are truly being blocked.
Generics: Reduce runtime errors through compile time checking
Threads: Prevent a UI from being blocked, while calculations occur.
Enums: Mainly because to make the BlazeDS communication easier.
... well I am repeating myself... there are a couple of reasons mentioned above.
I rather have a complex language that allows clean code, than a simple language that needs ugly workarounds and reduced testability in order to implement simple code patterns.
Design patterns seems to be your thing and that's great. But if your chosen language does not fully support their concepts, then you need to come up with new patterns that are specific to the platform. I think it's wrong to say that the big issue with ActionScript is that you can't completely clone Java patterns.
Why would coding in a simpler language be ugly? What would you be working around? Wouldn't a simpler language be less verbose, easier to learn and in turn create a slimmer API.
I never said that ActionScript should move towards Java. ActionScript should just get essential language features that are present in other modern languages for decades.
As your post pointed out Adobe IS NOT good at language design. They more or less hacked it to the point they are today. Actionscript evolved over time to become something very close to Java, but it has a lot more warts. Bringing threads into the mix requires a good language designer and I don't think Adobe is up for the task. Consider how much has been added to Java lately to help aide in making concurrency easier. I don't have faith it could be put into Actionscript at one time. It's a lot of machinery that has to be added.
I'm not convinced I want operator overloading as even in C++ it's bizarre and used in strange ways. STL's version of Set is a great example of ickyness that operator overloading can have (i.e. objects must overload '<' operator to be put into a set). What if I want to add something to a set, but not define an explicit order? SOL.
However, I would agree there is a need to allow objects to define equals() and hashCode() like in Java. HashMap structure is a great example of why. Another example of Adobe not being so good at language issues.
ASL-18 - Abstract classes and abstract methods
FP-811 - Complete support for Generic Types / Full Generic API
ASL-23 - Shared-memory multithreading
ASC-2583 - Private or Protected Constructors
ASL-9 - Method Overloading
ASL-10 - Operator overloading
(I had to remove the URLs to get past the spam filter.)
-James