Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of frishy@gmail.com designates
 209.85.216.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <14ab01ccd9bc$85d0e280$9172a780$@davidarno.org>
References: <14ab01ccd9bc$85d0e280$9172a780$@davidarno.org>
Date: Mon, 23 Jan 2012 13:32:37 +0000
Message-ID: 
 <CAN4oaEM_nP9GNzuqR-Biqk5otjwaOH7v49fy0DricegooVwsfw@mail.gmail.com>
Subject: Re: Apache Flex 3.7 - my planned mega-patch
From: Ryan Frishberg <frishy@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

I understand the frustration this is trying to solve, but I don't
think having an official release like this is a good idea. Imagine
someone picks up this release, and then wants to upgrade to Flex 4.x
later on--the backwards-compatibility story would be completely lost.

What you're proposing isn't necessarily bad and could be quite
helpful, but I think the right place for this would be in a separate
whiteboard clearly labelled as "Flex 3.x dead end" or something like
that so people clearly know that once they go down that path, there is
no hope of an easy 4.x upgrade. I'm even fine if this is promoted on
the Apache Flex page, but I'm just really against it as an official
release of the SDK.

Carefully moving some methods and properties to protected (or
mx_internal) is another story, and I'm all for doing that in the 3.x
branch and beyond.

Cheers,
Ryan

On 23/01/2012, 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.
>
>

-- 
Sent from my mobile device