Blog

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.