Flex has been open source for a while now, so you might wonder why there doesn’t seem to be more external, community-driven extensions to the library. It seems that the only source contributors are Adobe employees. I’ll pass on the theories on why Adobe might want to keep it this way. The purpose of this post is to look at why from a strictly technical point of view it’s really discouraging to try to extend the library. I’ve tried, and these are the problems I’ve run into.

  • Flex classes are huge. Adobe seems to have taken the « everything but the kitchen sink » approach to designing Flex, so you end up with huge blobs of code with tuff and features and whatnots that have nothing to do with the class’s purpose. So obviously a big class is harder to read and extend.

  • mx_internal. Everywhere you look in Flex classes you find variables that are part of the namespace mx_internal. Since this isn’t documented, it’s anybody’s guess why the more traditional private, internal, protected and public declarations aren’t enough. The thing is you actually can use mx_internal objects, you just have to know how to. So what it the intention? Don’t use mx_internal in your derived classes unless you’re really hardcore? I’m baffled, so if anyone has an explanation please leave it in the comments.

  • Using private instead of protected. Sometimes you need access to a variable from your subclass and it’s been declared private. This happens quite often. So you end up copying the class into your workspace to modify it instead of extending it as you should.

  • This isn’t so common as mx_internal, but still annoys. Instead of using a class reference, Flex sometimes uses a path reference to a file. « include “../core/Version.as”; ». Looks crappy, right? Yeah, it is. Suppose you’ve copied the class locally, as mentioned above. The path reference won’t work, and you need to jump through even more hoops to get the job done.

That wraps it up for now. To get a good exapmple of everything I mentioned, take a look at the mx.effects.effectClasses.MoveInstance class. It does a good job, but is long, unreadable and unextendable. Don’t get me wrong, I still like Flex otherwise I wouldn’t work with it and post about it, but sometimes it gets me down.