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 <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. > >
