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 <aha...@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" <jonbcam...@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 <rol...@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 <m...@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 <roge...@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 > >>>> roge...@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 | rol...@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
