>>If I'm not wrong, you did some deep experiments in DI and AOP, what can you >>say about performences ? did you do measurements ? if yes, how ?
Because of the VM limitations, the type of AOP I was most interested in was compile time. I was working on something like an AspectJ implementation. Some of the first features were things like compile-time mixins and interface implementation mapping, so that you can indicate an object needs to implement an interface, provide a mapping to a mixin and have the compiler mix those classes together . This meant that we can still have small and a relatively decoupled programming model, and yet let as avoid some of the costs that Alex was referring to. Effectively, at compile time, there are no extra function closures, function calls or delegations for the VM to deal with. My experiments with DI are very subjective. I was willing to pay the extra cost for instantiating an object as required to do DI. I very much care about testing objects and replacing their implementations. My feelings on this are pretty simple, yes, this introduces overhead, but it makes so many things faster to develop, maintain, test and extend than before that I am willing to take a performance degradation in some areas. However, this also means I don't have to take everything. Meaning that, if this is done properly, I could decide not to inject a heavy weight style manager. I could inject different implementations of some key features that are lighter-weight or perhaps no implementation at all. I could let people develop different binding implementations which work differently for different requirements. That flexibility, in my mind, means the Flex framework becomes a pay-as-you-go model. If you need all of the features in a large enterprise app, you can have them. However, I do not have to have all of the heaviest implementations in a mobile application. To me, the net result would be a reduction in size and an increase in speed. My thoughts, Mike -----Message d'origine----- From: Michael A. Labriola Sent: Tuesday, February 07, 2012 1:35 AM To: flex-dev@incubator.apache.org Subject: RE: Starting with the Whiteboard Code >> Writing unit tests for the framework is something that could be >>started now. The framework code is out there. >>Are the other ones logical tests? In other words: Would they need to >>be ported to a unit-test system? Unfortunately, with a few exceptions, unit tests *cannot* be written for the Flex framework. It isn't something that can be started. Unit tests by definition involve the writing of a test for a single object isolated from all other objects, not dependent upon global state, that also means they can't be dependent upon things like the frame rate and enter frame events. Looking at something like UIComponent, it references singletons and static classes (global state). It is coupled tightly with dozens of other objects. It relies upon the LayoutManager, which relies upon the frames, to function. There is nothing about the current state of Flex that approaches being testable in units. That's why so many of us have been arguing for refactoring for so long. Since most of our code involves extending or referencing Flex classes, and in most cases there aren't interfaces for those implementations, our code becomes un-unit-testable by association. Mike Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
