Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of aharui@adobe.com designates
 64.18.1.208 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Wed, 4 Jan 2012 14:09:21 -0800
Subject: Re: Flex modularity through composition and interfaces
Thread-Topic: Flex modularity through composition and interfaces
Thread-Index: AczLKGeJ0TMPBLCFQZi9PoJm5wGKgQABRrx9
Message-ID: <CB2A0E11.390EC%aharui@adobe.com>
In-Reply-To: 
 <CAAd0WrZJ+tgSk+AFdtTw8ik21bhqT-U8tihmM9h451mwiXP4ig@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Interfaces, modularity and DI are all good things.  But, IMHO, the key thin=
g
to keep in mind is that we are working in a constrained environment.  If yo=
u
are old enough to have tried to fit a DOS program in 640K, then that's a
good analogy to keep in mind.  It will all come down to trade-offs.  No one
philosophy can be universally applied.

Also, the AVM is not like the JVM.  For various reasons, language features
are not necessarily implemented as you might expect.  An empty interface
takes up 250 bytes in the SWF and about 1K of memory at runtime and causes
an empty interface constructor to run at when first used.  So, pairing ever=
y
class in the framework with an interface will likely degrade performance
unacceptably.

Same with modularity.  When I refactored UIComponent into 26 smaller
classes, small applications slowed down because of the "interstitial" time
calling between the different pieces.

And I predict the same with DI.  Injecting everything will slow things down
if you start injecting small things.  DI is definitely a good thing for man=
y
people at the application framework layer.  But at least one DI framework
has caused one major customer to suffer from performance problems.  And I
have yet to see a DI implementation that I think would perform well at the
framework level.

So, you have to sweat the details.  Know the costs of your changes.  That
means things like putting in interfaces where you know you need them, not
because you think you should have them.  Inventing an efficient DI mechanis=
m
that is good enough for the top 5 reasons we want it, but not implementing
it everywhere.

So, yes to interfaces, modularity and DI in principal.  The key is to make
the right trade-off in practice.


On 1/4/12 1:31 PM, "Jonathan Campos" <jonbcampos@gmail.com> wrote:

> The problem gets a bit hairy on parts of the framework that aren't readil=
y
> accessible (managers/singletons). These would be the first target for DI,
> allowing swappable components following good interfaces.
>=20
> Don't like StyleManager? Have a lightweight focus manager specifically fo=
r
> mobile? DI could help you switch these out without rewriting UIComponent.
>=20
> On Wed, Jan 4, 2012 at 3:28 PM, Roland Zwaga <roland@stackandheap.com>wro=
te:
>=20
>> I think everyone's pretty much on the same page as you Mike :)
>> Describing component functionality using sane interfaces will *allow* DI
>> much more easily. If some type of configuration for this can be supporte=
d
>> by the SDK, that would be awesome because existing DI frameworks could h=
ook
>> into those so that way everyone can keep on using their favorite
>> application framework.
>>=20
>> cheers,
>>=20
>> ROland
>>=20
>> On 4 January 2012 22:24, Michael Schmalle <mike@teotigraphix.com> wrote:
>>=20
>>> This is just a weird thought and I have no opinion on DI since it's lik=
e
>>> religion to most.
>>>=20
>>> Isn't the idea of OOP polymorphism, and the way you create it is throug=
h
>>> abstract interfaces? Correct me if I'm wrong here.
>>>=20
>>> Maybe I am from another planet but it seems to me, that the strength in
>>> Apache is to allow a democratic approach to creating a protocol agreed =
to
>>> by the majority of the community.
>>>=20
>>> What is the problem on agreeing on some interfaces that could be put in
>>> the core, for other outside DI libraries to implement.
>>>=20
>>> In this way, you would have a standard but allow anybody to create ther=
e
>>> own implementation. At the same time without having a concrete
>>> implementation IN the SDK you could still use the interfaces that could
>>> provide "sockets" for DI without the dependencies.
>>>=20
>>> Just a thought, this is the same thought I have about component design.
>>>=20
>>> Mike
>>>=20
>>>=20
>>>=20
>>> Quoting Rogelio Castillo Aqueveque <rogelio@rogeliocastillo.com>:
>>>=20
>>>  I agree on modularity, but I reckon dependency injection is a totally
>>>> different thing which has lots of very good libs out there... not sure
>> if
>>>> that should be part of the SDK.
>>>>=20
>>>> I believe that the focus should be on splitting the SDK into several
>>>> modules/libs, then think on interface design.
>>>>=20
>>>> R
>>>>=20
>>>> ---
>>>> Rogelio Castillo Aqueveque
>>>> rogelio@rogeliocastillo.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On 4/01/2012, at 6:11 PM, Jo=E3o Saleiro wrote:
>>>>=20
>>>>  +1
>>>>>=20
>>>>> I agree with reducing strong-coupled dependencies as the first
>> priority.
>>>>>=20
>>>>> I would also complement the use of interfaces with:
>>>>>=20
>>>>> - using dependency injection when possible
>>>>> - splitting the SDK into several libraries
>>>>> - support and advocate the use of Maven for managing dependencies (or
>>>>> something similar)
>>>>>=20
>>>>>=20
>>>>> Jo=E3o Saleiro
>>>>>=20
>>>>> On 04-01-2012 21:03, Michael Schmalle wrote:
>>>>>=20
>>>>>> Continuing the thread from "Committer duties and information"
>>>>>>=20
>>>>>> about setting interface priority to #1 in the future development fo
>>>>>> Flex.
>>>>>>=20
>>>>>> Mike
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>>=20
>> --
>> regards,
>> Roland
>>=20
>> --
>> Roland Zwaga
>> Senior Consultant | Stack & Heap BVBA
>>=20
>> +32 (0)486 16 12 62 | roland@stackandheap.com |
>> http://www.stackandheap.com
>>=20
>=20
>=20

--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui