FAME Chronicles #1: Long Classpaths & Local Var Declarations

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.

8 Replies to “FAME Chronicles #1: Long Classpaths & Local Var Declarations”

  1. 46 seconds down to 2 seconds.. If you compile 30 times, there’s your 20 minutes you saved to refactor your code a bit. Not bad!

  2. I’m using it on a pretty big project right now. Got it down to no warnings, and haven’t noticed any odd behavior. The product is going the major QA now, and nothing that has come up has been due to an MTASC/MM difference yet. My compile times aren’t that dramatic, but they are a fraction of MM’s.

  3. The inner defined local variables is the only thing I’ve had to go back and fix so far also which isn’t a big deal. The only problem is I have to go through and update any 3rd party classes I like using.

  4. I experienced the exact same thing!
    At work, I got sick of the MM compiler lunch breaks, so i got a ‘FAME’ setup going, and now I don’t even have time sip my coffee. About the local vars, I initially thought it was complete hogwash myself, until i asked a uber-programmer/coworker about it and he corrected me.

    Dude, it’s like deja vu…

  5. Jester,
    did you manage to have FAME (MTASC part) compiling AS files with Flex core classes ?

  6. re the inner variables, and not retyping them, guess thats ok – can understand its not really good programming -as per ‘Local variables scoping’ on the mtasc.org website)

    what i’ve found a pain is nested functions,which seem a different issue

    from the mtasc.org website
    that certainly stops a lot of code compiling on a current project I tried to use MTASC on – and a pain reworking the code to get rid of nested function which work ok on MM IDE (and are used in say Moock’s book)

    I sort of understand the difficulty the compiler has – but surely if the number of { does not equal the number of closing } it could stop proceedings then
    MM IDE can generate 71 consequent errors when you forget a paranthesis – but no-one has suggested nested functions are intrinsically bad

    seems a problem to me

Comments are closed.