Thanks for taking the time to share your insights into the gulf that exists between Flex and Silverlight. I know you've made your decision with regard to Flex, and I won't sway it one whit, but I feel obliged to respond with similar consideration. Again, I'm not looking to start a heated debate, just to throw in my 2 cents on your findings.
* Lack of support for generics
I'll give you that, generics are nice. But I've gotten by for years without them. They didn't come to Java until I'd exited that camp to come to AS3. I've found that usually the code that puts something into a collection only puts the same kind of items into that collection *by design*. Like interfaces, a contract would be nice and I'm sure it would make the IDE a lot wiser about what's going on in the app.
* Lack of support for covariance
I'd have to push back on this one. AS3 subclasses, when overriding methods of their super classes must implement the same or narrower types. (I.E. a method that takes a 'fruit' argument in the super class could take an 'apple' argument in the subclass.) This is the very definition of covariance.
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29 * Weak garbage collector (one has little control over it)
I hear that. It keeps you on your toes making sure you've unhooked things properly. This is one place where PureMVC helps a lot, since it provides a way to move the data between tiers, where you control all the references. Applications implemented on frameworks that use a lot of binding between the Model and View tiers end up with lots of invisible listener references that are put there by 'magic' when Flex does the binding. This makes it extremely difficult to unhook everything so that it will be freed when the GC reference count and mark and sweep passes take place. With PureMVC, binding is within the view hierarchy. If a view component with bindings back and forth between itself and its child components only, then when it is removed from the view hierarchy, it can be reclaimed along with its children. There references to each other are not enough to keep them around if nothing else references them.
* No destructor or dispose pattern
Another thing that would enhance the garbage collector. PureMVC offers an onRemove method that is called when Proxies and Mediators are called, and this is generally used to unhook services and view components from within your program.
* Doesn't solve the memory leak issues associated with event handlers*
Well, you do have to take responsibility for removing listeners you've added. Beyond that, be careful with the Flex binding, as that can add to your woes. I understand that the latest Flash 10 release has made some improvements.
http://www.gskinner.com/blog/archives/2008/07/additional_info.html * Implicit interface support only; no support for explicit interfaces
Thought this one might be handled with namespaces, but not really. Oh, well. I rarely have classes that implement multiple interfaces which have the same method name defined, though.
* Lack of support for lambda expressions
OK. I've managed to program since 1982 without needing lambda expressions. I see what they do, but I can't imagine how they'd change my life if I had them.
* Asynchronous, yes, but multithreaded, no**
And along with a threaded environment comes the extra responsibility of making sure that everything is threadsafe. Imagine how much worse the state of Flex RIAs would be if that were also expected of the developer. I'm not saying threads are bad, I'm just saying it's more a more complex paradigm.
* ActionScript is not a stand-alone language
Sure it is. The flash.* and mx.* classes are not part of ActionScript they are included in the Flash and Flex libraries. Furthermore, the Actionscript Virtual Machine used by the Flash Player is open source. The language itself has no ties to the Flash player.
* Declaring type after the variable is awkward
After years of doing it the other way round in Java, I've come to like the postfix syntax better. I'm declaring a public static method named something which takes some arguments of some types and returns some value. I pretty sure any awkwardness on this point comes from what you're familiar with rather than some inherent wrongness of the syntax.
-=Cliff>