flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Labriola" <labri...@digitalprimates.net>
Subject RE: Starting with the Whiteboard Code
Date Sun, 12 Feb 2012 20:13:33 GMT

>>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,

-----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.


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. 

View raw message