Top Ten of Missing Features in Adobe ActionScript (Updated)

Wednesday, February 17. 2010

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.


Posted by Carsten Schlipf Filed under Flex.
Comments (14) Trackbacks (0)
Leave a comment or send a Trackback from your Blog.

Trackbacks


Trackback specific URI for this entry
    No Trackbacks

Comments


    #1 JesterXL on 01/26/10 at 04:54 AM [Reply]
    *#7: Check out valueOf(); if you override that, it may help (not sure if exactly what you want).

    #9: Check out Dictionary; she supports custom types as the key.
    #1.1 Carsten Schlipf on 01/26/10 at 08:17 AM [Reply]
    *Hi Jester,

    #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.
    #2 Jesse Freeman on 01/26/10 at 05:04 AM [Reply]
    *Hate to point this out but I would actually consider all of your complaints against ActionScript itself and not Flex. If you were doing a top 10 list of things missing from Flex it would be something like:

    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!
    #2.1 Carsten Schlipf on 01/26/10 at 08:21 AM [Reply]
    *Hi Jesse,

    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!
    #3 Alex Bustin on 01/26/10 at 08:40 AM [Reply]
    *Why do you need these features? Why will it make things better? Will it make things simpler and less confusing?

    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/
    #3.1 Carsten Schlipf on 01/26/10 at 09:33 AM [Reply]
    *Sorry - I don't agree. Your proposal might be OK for simple UIs. But Flex/ActionScript is target towards the RIA space and we have fairly complex UIs, were the runtime behavior is hard to test in every corner case. Continuous integration would be very hard to achieve, if most programming errors would not have been found at compile time.
    #3.1.1 Alex Bustin on 01/26/10 at 05:28 PM [Reply]
    *Why do you need a complex framework and language to make complex UI? I find that the lighter and simpler the API and language, you more expressive you can be. And yes, I make complex UIs too.

    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.
    #3.1.1.1 Carsten Schlipf on 01/26/10 at 08:34 PM [Reply]
    *Well, the need for Abstract classes is obvious or not? Abstract classes are essential for a lot of patterns.

    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.
    #3.1.1.1.1 Alex Bustin on 01/27/10 at 01:53 AM [Reply]
    *I know what each of those features does. That's not what I asked. What I want to know is how their absence is blocking you from creating what you want to create.

    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.
    #4 Cesare on 01/26/10 at 04:00 PM [Reply]
    *In general I'd prefer as3 to move toward scala/groovy, rather than java.
    #4.1 Carsten Schlipf on 01/26/10 at 04:43 PM [Reply]
    *Don't know Scala, but Groovy is similar to Java and provides all the points mentioned above also. So this is the same direction.

    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.
    #5 Charlie Hubbard on 01/26/10 at 10:09 PM [Reply]
    *I agree we need concurrency mechanisms, but not threads. Lots of developers don't even realize there are other constructs that give them concurrency that are NOT threads. I'd much rather see something like Erlang or Scala style concurrency with Lightweight Processes or Actors. Threads bring with them a complete set of serious problems most developers can't handle. Determinism goes out the window, and then synchronizing on data structures to keep it altogether. I'd even go so far to say Threads in Java, as nicely designed as they are, don't work well for most situations.

    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.
    #6 Sharedtut on 02/02/10 at 05:06 AM [Reply]
    *Would love to see actionscript 3 grow into an essential language like c+
    #7 James Ward on 02/17/10 at 06:35 PM [Reply]
    *Make sure you add your comments and votes to the feature requests on bugs.adobe.com:

    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

Add Comment

HTML-Tags will be converted to Entities.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA