I remember reading something about this a year ago on Flashcoders, but never ran into it until today. Basically, if you extend a class that has a getter and a setter on it, your sub-class can access them just fine. However, if your sub-class defines a getter or setter of the same name, it overwrites the one on the superclass.
So, if make a new setter function that does something slightly different in the sub-class, since the sub-class can no longer call the getter, it fails.
That blows.
Was testing out MTASC yesterday morning to see how fast it would compile our project at work, which has about 98 classes. It takes roughly 30 to 46 seconds to compile the main FLA in Flash. After 20 minutes of code modifications, I managed to get just warnings (but it’ll still compile).
It takes under 2 seconds.
The warnings kind of suck because basically, some of my classes had to have their symbolName properties be the same to work. Why? It sounds to me, after talking to Darron about it, like Flash’s internal Object.registerClass doesn’t like long names. One warning, however, I couldn’t get rid of; this was because the classpath was longer than 64 characters, and Flash doesn’t allow you to have linkageID’s longer than that. So, for the time being, unless I can find out why MTASC can’t inject the class into the existing SWF correctly, I’ll just have to refactor it to get it to compile without warnings.
The 20 minutes of code changes were local variable definition changes. Basically, this is the ONLY THING I have found different to coding for MTASC vs. for Flash. It doesn’t like inner defined local variables (like in nested loops and if then statements), nor does it like the same variable name typed twice in the same function. Naturally, I thought this was bs, but before communicating such, I asked a co-worker who was more experienced, and asked what he thought. After explaning on how other languages don’t allow you to do both of those things, and why it is ambiguous, and leads to errors where a function is dependent on a variable to be set (which is really bad for Flash since currently, it won’t throw exceptions for such things), so I understand why it’s bad to code that way, and it makes sense. Thus, I believe it’s a good thing why MTASC doesn’t support this bad practice, and I have no problems adjusting my coding style for it.
Still, though, I wish we could get more official reports on the integrity of SWF’s MTASC generates. I am not sure what I mean by official, but I guess like real-world projects that have been deployed to big clients, thus giving me faith in the quality of SWF that MTASC can produce on it’s own vs. SWF’s created in Flash that it just injects classes into.
Her majesty suggested I put my money where my mouth is, and show an example created using the technologies talked about in my previous post. Therefore, I created a dynamic image slideshow using FAME (Flashout + ActionScript Development Tool + MTASC + Eclipse). I did not use the Flash IDE in any way; I coded and tested all within Eclipse.
FAME Slideshow Source – ZIP
This is awesome!
However, one thing is abundantly clear; even with the ability to utilize Flash MX 2004 components… we need an open source component architecture.
I ran through the tutorial in the Towards Open Source Flash Development article. Upon compiling my first open source SWF, a “Wow!” escaped my lips through a nervous laugh; my hands started to shake. When I got the Alert component part to work, the same thing happened again… “Wow! HA HA!!!”
There are a plethora of instructions, both on the site, and in each of the pieces’ intsall instructions… but none of it was painful at all to install and configure. And Eclipse, geez, so far it feels pretty nice. I’ve tried for 4 years, unsuccessfully, to use another external editor other than Flash to create & manage my ActionScript in. I won’t know for another few weeks if we have a winner, but I must say, I like the workflow so far. Why?
I don’t have to leave… sort of.
The “hack” as it’s described ActionScript.com’s site doesn’t feel that hackish at all. You just instantiate your class & include the necessarey components in the library. That’s not hard, nor evil feeling at all; it’s a fact of Flash development life.
More investigation is necessarey to see how it compiles my current projects, how diffucult it is to set them up in Eclipse, and what, if any, code is needed to change to ensure it compiles correctly with MTASC.
So far, the tabbed interface, a Project panel that actually works well, an Outline view (which has yet to prove its usefulness), all visible at the same time with colored code… feels nice. The Flashout tab makes things feel professional. I have a SWF, traces, and compiler configuration controls built right in.
Why am I using the Flash IDE again? This is cool! Let’s see if I’m singing the same tune in 2 weeks; that’s been my Acid test over the past 4 years. I am recently starting to have to utilize Java at work, so that adds a few points for the Eclipse route.
I encourage others to try it out.
Reference links:
I’ve been trying to come up with an anacronym from the letters of “E”, “A”, “M”, and “F” to describe these various technologies that make up this new workflow. FAME, perhaps?