Modular applications, directory structure, and RSLs

[puremvc]

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>

[estaylorco]

Hi Cliff,

No problem.  And, of course, the spirit of my post was one of exchange, not debate.  To that end, I should respond so that lookers-on benefit from a refinement of this exchange.

I'd have to push back on this one.  (referring to covariance)

Actually, those of us who look for covariance think of it more in terms of return types, not arguments.  That's where we need it most (I'm afraid Wikipedia is incomplete here.  We would have to turn to Bertrand Myer's Object-Oriented Software Construction text for the complete definition).  Covariance over arguments isn't very interesting, albeit necessary.  When the conversation switches to arguments, well then I'm looking for contravariance.  Eiffel spoiled me with its robust support of both of these features.  In fact, I'm rather lost without covariance over return types.  I'm looking forward to .NET 4.0 for this, among other, reasons.  Incidentally, I see a few places in the codebase of PureMVC where covariance could be of benefit.

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.

I felt the same way as you...until I went all in.  My goodness, why did it take so long for lambdas to work their way into mainstream?  It's quickly becoming the case for me that I wouldn't know how to program without them anymore.  I find myself using them naturally.  They're so powerful, so expressive, and so succinct.  They also tremendously improve the readability of the code.

Sure it is. The flash.* and mx.* classes are not part of ActionScript...

I missed this, then.  I stand corrected.  It wasn't a deal-breaker, though.

After years of doing it the other way round in Java, I've come to like the postfix syntax better.

Yes, Eiffel does it this way as well, and it drives me crazy there, too.  You're right: It's just a matter of what you get used to.  It wasn't a deal-breaker either, though.  But I have read where other die-hard ActionScript programmers don't care for the postfix approach too much, either.

Anyways, this is good stuff.  Thanks for your awesome reply.

Eric

[jpwrunyan]

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.

I felt the same way as you...until I went all in.  My goodness, why did it take so long for lambdas to work their way into mainstream?  It's quickly becoming the case for me that I wouldn't know how to program without them anymore.  I find myself using them naturally.  They're so powerful, so expressive, and so succinct.  They also tremendously improve the readability of the code.

Ok, I've looked at the wikipedia entry and I still can't fathom what lambda functions are really for.  Honestly, though, the entry didn't appear to be written for a layman.  I may be a programmer, but I am not a computer scientist.  What's the point of using lambda functions for the Pythagorean Theorem?

Also, thanks for the discussion, particularly regarding the interfaces.  I also couldn't comprehend the point of explicit/implicit interfaces until you mentioned namespaces and overlapping method names.  Now I understand the issue completely.

If you want one criticism of AS 3 that neither of you have mentioned yet, it's that there is no way to override namespace functions without declaring use of the namespace at the beginning of the package.

You can do this:

:

import mx.core.mx_internal
use namespace mx_internal
...
override function mxInternalMethod():void {}

but not this:

:

import mx.core.mx_internal
...
override mx_internal function mxInternalMethod():void {}

I guess maybe there's a good reason for it and/or I am oblivious of the theory behind using namespaces, but it caused me a lot of heart-ache because of a bug that arose when importing CSSStyleDeclaration in a class that also declared use namespace mx_internal.

anyway...