From flex-dev-return-157-apmail-incubator-flex-dev-archive=incubator.apache.org@incubator.apache.org Wed Jan 4 21:35:47 2012 Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E4267B27E for ; Wed, 4 Jan 2012 21:35:47 +0000 (UTC) Received: (qmail 9324 invoked by uid 500); 4 Jan 2012 21:35:47 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 9293 invoked by uid 500); 4 Jan 2012 21:35:47 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 9285 invoked by uid 99); 4 Jan 2012 21:35:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jan 2012 21:35:47 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.213.175] (HELO mail-yx0-f175.google.com) (209.85.213.175) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jan 2012 21:35:41 +0000 Received: by yenm12 with SMTP id m12so8832230yen.6 for ; Wed, 04 Jan 2012 13:35:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.163.18 with SMTP id q18mr22583754ano.16.1325712920875; Wed, 04 Jan 2012 13:35:20 -0800 (PST) Received: by 10.100.153.3 with HTTP; Wed, 4 Jan 2012 13:35:20 -0800 (PST) In-Reply-To: References: <20120104160346.14214ryrloryh4fm@www.teotigraphix.com> <4F04C070.6020401@webfuel.pt> <815DF771-823D-476E-B8BC-609AFA887442@rogeliocastillo.com> <20120104162437.71964i65lho6luhh@www.teotigraphix.com> Date: Wed, 4 Jan 2012 22:35:20 +0100 Message-ID: Subject: Re: Flex modularity through composition and interfaces From: Roland Zwaga To: flex-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=0016e68dec93b9125204b5ba972b X-Virus-Checked: Checked by ClamAV on apache.org --0016e68dec93b9125204b5ba972b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Or even better, don't need StyleManager? Throw it out completely and save a buttload of memory :) On 4 January 2012 22:31, Jonathan Campos 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. > > Don't like StyleManager? Have a lightweight focus manager specifically fo= r > mobile? DI could help you switch these out without rewriting UIComponent. > > On Wed, Jan 4, 2012 at 3:28 PM, Roland Zwaga >wrote: > > > I think everyone's pretty much on the same page as you Mike :) > > Describing component functionality using sane interfaces will *allow* D= I > > much more easily. If some type of configuration for this can be support= ed > > 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 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 agree= d > 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 cou= ld > > > provide "sockets" for DI without the dependencies. > > > > > > Just a thought, this is the same thought I have about component desig= n. > > > > > > Mike > > > > > > > > > > > > Quoting Rogelio Castillo Aqueveque : > > > > > > I agree on modularity, but I reckon dependency injection is a totall= y > > >> different thing which has lots of very good libs out there... not su= re > > 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=E3o 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=E3o 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 f= o > > >>>> Flex. > > >>>> > > >>>> Mike > > >>>> > > >>>> > > >>>> > > >> > > >> > > > > > > > > > > > > -- > > regards, > > Roland > > > > -- > > Roland Zwaga > > Senior Consultant | Stack & Heap BVBA > > > > +32 (0)486 16 12 62 | roland@stackandheap.com | > > http://www.stackandheap.com > > > > > > -- > Jonathan Campos > Dallas Flex User Group Manager > http://www.d-flex.org/ > blog: http://www.unitedmindset.com/jonbcampos > twitter: http://www.twitter.com/jonbcampos > --=20 regards, Roland --=20 Roland Zwaga Senior Consultant | Stack & Heap BVBA +32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com --0016e68dec93b9125204b5ba972b--