>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 <jonbcam...@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 <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 > -- regards, Roland -- Roland Zwaga Senior Consultant | Stack & Heap BVBA +32 (0)486 16 12 62 | rol...@stackandheap.com | http://www.stackandheap.com
