I am just one vote, but you can count on my -1. As we discussed, I think changing everything from private to protected is just as bad as not putting the initial consideration into the extensible architecture.
Mike -----Original Message----- From: Quentin Le Hénaff [mailto:lek...@gmail.com] Sent: Monday, January 23, 2012 8:20 AM To: flex-dev@incubator.apache.org Subject: Re: Apache Flex 3.7 - my planned mega-patch I agree with the private => protected shift, but we must think about using mx_internal instead ; this is not really object nad I never reeally understood what it is either but there some stuff that should not be overridden The best solution btw is the use of delegation instead of inheritance, but that is more expensive and should be planned for the whole sdk IMHO we must have a branch for all the 3.X stuff and components or we may be able to do nothing and this is really bad as Flex 3 is mainly used. No support of it will just sign a quicker death of Flex... On Mon, Jan 23, 2012 at 2:32 PM, Ryan Frishberg <fri...@gmail.com> wrote: > 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 <da...@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 > Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
