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 >
