Understanding class "fingerprints" with SWC files

Question

I'm sorry for a very poorly structured question. I just run out of English... I hope one of you guess what's the problem and can provide better words to describe it!
I'm having hard time understanding how classes from SWC files are handled when the app is complied with Flash Builder. We have about 50 SWC files, all compiled from corresponding FLA files. Their libraries contain elements that have AS3 linkages and in the end, there are plenty of classes involved. The classes are packaged in SWC files and Flash Builder finds them just fine. Some AS3 linkages have the same name, which is OK, because they are essentially the same library elements and we don't want to have duplicates in the app. Also plenty of AS3 linkages have same base classes, which means plenty of SWC files carry those base class definitions too, but only one is really needed.
Sometimes everything works, sometimes something breaks. It almost seems like the moon phase affects whether the end result works or not... Sometimes recompiling SWC files helps with one problem, but breaks something else. This leads me to guess, that Flash Builder selects the available classes based on the date of the SWC files? If more than one SWC files have the same class definition, Flash Builder selects the newest?
The error we encounter, is "AS3 Error #1034: Type Coercion failed:", which is related to having one of these shared AS3 linkages (let's say SharedClass) on the timeline of a MovieClip. This means it is *not* created with the new keyword! So if SharedClass is defined in SWC1 and SWC2, maybe Flash Builder decides to use the one from SWC1. This means that elements from SWC2 that use SharedClass will use SWC1's definition of it. But for some reason this doesn't always work as it should. It helped, when I changed how AS3 references the instances declared on the timeline: "var mySharedClassObject:SharedClass" --> "var mySharedClassObject:*" but I don't understand why...
This leads me to believe, that the SharedClass in SWC1 and SWC2 have different "fingerprints" which makes the class casting break in some situations. When I use "new" keyword, everything works, because it doesn't matter which definition will be used. But when the class is created on the timeline, it may require exact fingerprint of that class?
Most of those cases are easily cleaned, but I'm also running into problems with some classes that have only one definition! If the AS3 linkage of SWC1 has the same base class, than AS3 linkage of SWC2, we run into the same problem. This is because both SWC1 and SWC2 contain the definition of the base class and maybe they have different fingerprints, even though our base classes are just AS3 files (no linkages).
Does this make any sense?
Anyone know a way to see the class name collisions and potential problems?

Answer 1

If different SWC are using exactly the same class, there’s no problem. If more than one is using the same named class, and the two or more copies are different, they it’s down to the order they get compiled, and that can vary.
Make sure that everywhere that a class has the same name, it’s identical to the other ones. Remember that MovieClips become classes too, so if you have a shared library item named “title”, and it’s different for each SWC because the graphic instead the MovieClip is different, then you’ll get big problems.
One easy solution is to put the classes into a dedicated folder, like:
src/com/yourname/game1/Title.as
and:
src/com/yourname/game2/Title.as
instead of:
src/com/yourname/games/Title.as
You will end up with a lot of identical things in memory, but they have a different path, and won’t clash with each other.
Another thing to know, if you use GetDefinitionByName(“class1”), the main document class needs to know about those classes. This will solve that problem:
public var namedClasses:Array = [class1,class2,class3];
Then when the compiler is doing its thing, it doesn’t go into shock when an embedded SWC is creating an instance of a class from the shared name.
So, make sure things are truly identical, or make sure they have a different path.