On 11/7/13 11:43 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>>>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? I think I'm still unclear what you plan to do about Sprite. Is that "outside" so there is no placeholder, or are you still creating a placeholder for it? And if you think there should be a placeholder, what APIs does it have? Maybe I just need a more explicit example so I understand the advantages of it. I think there are different kinds of classes in FlexJS. There are "top-level" classes like Button that need to have matching API surfaces in JS. But then there are classes like DropDownListList.as which we use on the AS side as part of a DropDownList but there really is no need for it on the JS side in the DropDownList that does plain text and simply wraps a <Select> tag. IOW, there are pieces we can leverage in a browser that we have to create in AS, and I don't see any advantages to creating empty placeholder classes for them in JS, and vice versa. But in general, there are several classes in FlexJS that could use a scrub now that we have interfaces and can load beads in JS. SimpleStatesImpl.as/js is a good example so thanks for scrubbing that one, but I'm still not sure it makes sense to have every .as have a matching .js file. I'd rather have a tool that rolls-up or flattens the APIs for a class and its superclasses and compares them and doesn't care quite so much about what goes on inside and can ignore some aspects of inheritance and inherited APIs. It should certainly be a goal to make what goes on inside as similar as possible to the other side, but I don't think we should have a hard rule that it must be the same. Anyway, I'm shutting down for the night, -Alex > >>>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
