Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: "Michael A. Labriola" <labriola@digitalprimates.net>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Subject: RE: Starting with the Whiteboard Code
Thread-Topic: Starting with the Whiteboard Code
Thread-Index: 
 AQHM46gD0bOmdzfBZ06thj2tHUNCLJYt7ysAgAAB2YCAALl3gIAAIRYAgAAigoCAAQYMgP//404wgACvMYCAAAnbgIAAHpiAgAAEsAD//+N/QIAAhK8AgAifBbA=
Date: Sun, 12 Feb 2012 20:13:33 +0000
Message-ID: 
 <EB6F7A48D477254EAB8F675582F80CD711D757@DPSBS1.digitalprimates.local>
References: <CB5598C2.73EB%cframpto@adobe.com>
 <4F30337E.9020803@leichtgewicht.at>
 <EB6F7A48D477254EAB8F675582F80CD7117B0E@DPSBS1.digitalprimates.local>
 <BLU162-ds7E7E993EB82A9C4214B20B4750@phx.gbl>
In-Reply-To: <BLU162-ds7E7E993EB82A9C4214B20B4750@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


>>If I'm not wrong, you did some deep experiments in DI and AOP, what can y=
ou 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. S=
ome of the first features were things like compile-time mixins and interfac=
e implementation mapping, so that you can indicate an object needs to imple=
ment an interface, provide a mapping to a mixin and have the compiler mix t=
hose classes together .=20

This meant that we can still have small and a relatively decoupled programm=
ing model, and yet let as avoid some of the costs that Alex was referring t=
o. Effectively, at compile time, there are no extra function closures, func=
tion calls or delegations for the VM to deal with.=20

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 abo=
ut testing objects and replacing their implementations. My feelings on this=
 are pretty simple, yes, this introduces overhead, but it makes so many thi=
ngs faster to develop, maintain, test and extend than before that I am will=
ing to take a performance degradation in some areas. However, this also mea=
ns I don't have to take everything.=20

Meaning that, if this is done properly, I could decide not to inject a heav=
y weight style manager. I could inject different implementations of some ke=
y features that are lighter-weight or perhaps no implementation at all. I c=
ould let people develop different binding implementations which work differ=
ently for different requirements. That flexibility, in my mind, means the F=
lex framework becomes a pay-as-you-go model. If you need all of the feature=
s in a large enterprise app, you can have them. However, I do not have to h=
ave 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=
.=20

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=20
>>started  now.  The framework code is out there.
>>Are the other ones logical tests? In other words: Would they need to=20
>>be ported to a unit-test system?

Unfortunately, with a few exceptions, unit tests *cannot* be written for th=
e Flex framework. It isn't something that can be started. Unit tests by def=
inition 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.=
=20
It relies upon the LayoutManager, which relies upon the frames, to function=
.

There is nothing about the current state of Flex that approaches being test=
able in units. That's why so many of us have been arguing for refactoring f=
or so long. Since most of our code involves extending or referencing Flex c=
lasses, 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 privil=
eged or confidential. Any dissemination, distribution or copying of this tr=
ansmission by anyone other than the intended recipient is strictly prohibit=
ed. If you have received this transmission in error, please notify the send=
er immediately by e-mail or telephone and delete the original transmission.=
 Thank you.=20