>>At this point in the development of the framework, no. Premature >>optimization and all thatŠ I'd maybe mark it as a TODO. > Why would that be premature optimization? I guess I'm now confused as to > where you want to put the abstraction differences? Making all > Sprite/DisplayObject APIs available on the JS side seems more of a Vanilla > plan than a FlexJS plan.
Ok, that's where I think I didn't make myself clear: I think we should match the class structure of the FlexJS framework, NOT anything it imports from outside that framework. So in my last commit, on SimpleStateImpl.js, I didn't create a placeholder for 'flash.display.DisplayObject'. In short: if it's a class or an interface in the AS FlexJS framework, I say we match it in the JS framework, for all the reasons I brought up earlier. If not, we try to live without it. This is not always possible, since e.g. AS-only projects need 'flash.display.Sprite', but in most of those cases we can get away with just an empty placeholder class on the JS side. Agreed? >>Remember, there is a second compiler (Closure) in the tool chain >>which takes care of most of the 'bloat' when it is creating release code. >>All those interfaces and nested classes go away, as they contain no >>actual, >>executable code pathways. > What about methods? Does it remove unused APIs? How can you know when an > externally loaded "module" won't need that seemingly unused API? GCC can work with modules, in order to allow for 'on demand' class loading. But I think even if you use these modules, you will have to recompile the entire project in order for the compiler to know all dependencies and relationships between modules. I don't think is possible to recompile just one module and having it work with a previously compiled 'main' application. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
