incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Campos <jonbcam...@gmail.com>
Subject Re: Flex modularity through composition and interfaces
Date Wed, 04 Jan 2012 22:12:32 GMT
I'm with you Alex. Definitely hear what you are saying and would like to
solve this issue.

On Wed, Jan 4, 2012 at 4:09 PM, Alex Harui <aharui@adobe.com> wrote:

> Interfaces, modularity and DI are all good things.  But, IMHO, the key
> thing
> to keep in mind is that we are working in a constrained environment.  If
> you
> 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
> every
> 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
> many
> 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
> mechanism
> 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
> readily
> > accessible (managers/singletons). These would be the first target for DI,
> > allowing swappable components following good interfaces.
> >
> > Don't like StyleManager? Have a lightweight focus manager specifically
> for
> > mobile? DI could help you switch these out without rewriting UIComponent.
> >
> > On Wed, Jan 4, 2012 at 3:28 PM, Roland Zwaga <roland@stackandheap.com
> >wrote:
> >
> >> 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
> supported
> >> by the SDK, that would be awesome because existing DI frameworks could
> hook
> >> into those so that way everyone can keep on using their favorite
> >> application framework.
> >>
> >> cheers,
> >>
> >> ROland
> >>
> >> On 4 January 2012 22:24, Michael Schmalle <mike@teotigraphix.com>
> wrote:
> >>
> >>> This is just a weird thought and I have no opinion on DI since it's
> like
> >>> religion to most.
> >>>
> >>> Isn't the idea of OOP polymorphism, and the way you create it is
> through
> >>> abstract interfaces? Correct me if I'm wrong here.
> >>>
> >>> 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.
> >>>
> >>> What is the problem on agreeing on some interfaces that could be put in
> >>> the core, for other outside DI libraries to implement.
> >>>
> >>> In this way, you would have a standard but allow anybody to create
> there
> >>> 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.
> >>>
> >>> Just a thought, this is the same thought I have about component design.
> >>>
> >>> Mike
> >>>
> >>>
> >>>
> >>> Quoting Rogelio Castillo Aqueveque <rogelio@rogeliocastillo.com>:
> >>>
> >>>  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.
> >>>>
> >>>> I believe that the focus should be on splitting the SDK into several
> >>>> modules/libs, then think on interface design.
> >>>>
> >>>> R
> >>>>
> >>>> ---
> >>>> Rogelio Castillo Aqueveque
> >>>> rogelio@rogeliocastillo.com
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 4/01/2012, at 6:11 PM, João Saleiro wrote:
> >>>>
> >>>>  +1
> >>>>>
> >>>>> I agree with reducing strong-coupled dependencies as the first
> >> priority.
> >>>>>
> >>>>> I would also complement the use of interfaces with:
> >>>>>
> >>>>> - using dependency injection when possible
> >>>>> - splitting the SDK into several libraries
> >>>>> - support and advocate the use of Maven for managing dependencies
(or
> >>>>> something similar)
> >>>>>
> >>>>>
> >>>>> João Saleiro
> >>>>>
> >>>>> On 04-01-2012 21:03, Michael Schmalle wrote:
> >>>>>
> >>>>>> Continuing the thread from "Committer duties and information"
> >>>>>>
> >>>>>> about setting interface priority to #1 in the future development
fo
> >>>>>> Flex.
> >>>>>>
> >>>>>> Mike
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> regards,
> >> Roland
> >>
> >> --
> >> Roland Zwaga
> >> Senior Consultant | Stack & Heap BVBA
> >>
> >> +32 (0)486 16 12 62 | roland@stackandheap.com |
> >> http://www.stackandheap.com
> >>
> >
> >
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>


-- 
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message