Hi Armencho, 2009/11/9 armen...@gmail.com <armen...@gmail.com>: > So, any suggestions, Daniel? :-) > > What do you think about implementing class stub generation in swfmill?
Sorry for the delay responding. I’ve been trying to get a better idea of what’s going on so I could post a more detailed reply but I haven’t had much chance yet. Anyway, I had time for a very brief investigation, so here are my findings. I’m going to be a bit vague on technical details because I haven’t had a chance to look too closely. I had thought that when you specify an id attribute on a clip in the simple dialect, that swfmill automatically associates that clip with the AS3 class of the same name (if it exists). It turns out that it does not do that. In fact, the value attribute becomes the linkage id of the clip. As far as I can tell, when compiling for AS3, haxe automatically associates classes with movie clips whose linkage id is the same as the fully qualified name of the class. as3compile and mxmlc do *not* do this, so it is not possible to associate clips with as3compile- or mxmlc-compiled classes using the simple dialect. I definitely agree that this will not do -- I want swfmill to be useful for constructing asset libraries for all compilers. For AS2, the simple dialect currently sets class associations according to the value of the class attribute, but this does not work for AS3. It should be a reasonably simple matter to extend this to work with AS3 -- see the register-class template in src/xslt/simple-tools.xslt. The trick should be to check if the as3 attribute is set at the root of the simple XML, and if it is, replace the DoInitAction tag with an appropriate SymbolClass tag (see the SWF spec for details). Generating class stubs is a separate issue. It should only be necessary if you can’t or don’t want to write a class for each exported symbol. In most cases I think it would be more appropriate to write a utility to generate class stubs in your preferred language. This approach has the advantage that you can construct instances of your clip using the new operator, which the compiler can check statically for errors. Despite that I am not against generating class stubs in swfmill. In particular it is useful for the case where you are instantiating clips loaded from an external SWF at runtime. The correct place to generate class stubs is probably immediately before generating the SymbolClass tag discussed above. Patches for this are very welcome, or I will work on this myself eventually. Right now, however, I am more focused on closing the known bugs. Hope this helps, Dan. _______________________________________________ swfmill mailing list swfmill@osflash.org http://osflash.org/mailman/listinfo/swfmill_osflash.org
