incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florian Salihovic" <Omega-...@gmx.de>
Subject Re: Apache Flex 3.7 - my planned mega-patch
Date Mon, 23 Jan 2012 13:26:36 GMT
Uhm, i'm just curious: when patching 3.x, that would require patching the Halo components in
Flex version > 3 as well to be patch to not break compatibility when people migrate their
components and projects to later versions of the framework. I can't really tell about the
work and effort that has to be put into it, but wouldn't it be more effective, when it comes
to pushing the SDKs, to put the energy into the current frameworks?

Just a question though.

-------- Original-Nachricht --------
> Datum: Mon, 23 Jan 2012 07:17:32 -0500
> Von: Nicholas Kwiatkowski <nicholas@spoon.as>
> An: flex-dev@incubator.apache.org
> Betreff: Re: Apache Flex 3.7 - my planned mega-patch

> I don't know about taking the shotgun approach and making EVERYTHING
> private -- but I do have my own list of variables/functions that should be
> changed from private to protected.  I wouldn't veto the careful approach
> of
> making the change...
> 
> -Nick
> 
> On Mon, Jan 23, 2012 at 5:48 AM, David Arno <david@davidarno.org> wrote:
> 
> > When we get the source for Flex 3.6, have resolved legal issues, patched
> > missing features etc, I'm expecting that we will make a 3.7 release. I'm
> > assuming most people would prefer we concentrated on Flex 4 and plans
> for
> > Flex 5, rather than on developing Flex 3 further. To that extent, I plan
> on
> > submitting a Flex 3 patch that can neatly be described as:
> >
> > /private/protected/g
> >
> > Because of the poor structure of Flex 3, inheritance is the only way to
> > create new components. Being unable to override behaviour of the parent
> > component causes lots of hacks, copying and pasting of code from
> > grandparent
> > classes etc. All these issues could be fixed by making everything
> > protected.
> > As (I assume) we only plan on creating bug fix future releases of Flex
> 3,
> > tying our hands with the extra contractual requirements of protected
> > members
> > shouldn't be a problem.
> >
> > This suggestion applies only to Flex 3. Doing this with Flex 4 would be
> a
> > big mistake IMO. And if we design Flex 5 right, it'll become a complete
> > non-issue with that release.
> >
> > Before I undertake this work, I want to check that the committers won't
> > veto
> > it. So I wanted to get people's views on the matter now.
> >
> > David.
> >
> >

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Mime
View raw message