incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Zwaga <rol...@stackandheap.com>
Subject Re: Flex modularity through composition and interfaces
Date Wed, 04 Jan 2012 22:25:48 GMT
>From what I understood about the DI features in the framework in Labriola's
talk at the flex summit, these would actually happen at compile-time, so
its not the same DI functionality we're used to when building applications
(like Parsley/Swiz/Spring/etc).
Interesting details by the way about the degrading performance when using
interfaces, that's good to know. And slightly unnerving too....

Roland

On 4 January 2012 23:12, Jonathan Campos <jonbcampos@gmail.com> wrote:

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



-- 
regards,
Roland

-- 
Roland Zwaga
Senior Consultant | Stack & Heap BVBA

+32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com

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