Object-oriented languages support private access because hiding implemention details is essential to producing evolvable code. We try to figure out what the "interface" of a class should be, and we expose that and no more. Otherwise the class becomes so brittle that we can't change it without breaking compatibility... "Somebody might be calling foo() and it still has to do exactly what it did in 2.0.1 or their code will break." An alarmingly large percentage of our time is already spent on that kind of compatibility issue. If you can find a book on OO design that says "Make everything public unless you have a great reason for it to be private", I'd like to know about it. IMHO, we've done a good job of exposing the right APIs for application developers, but a poor job of exposing the right ones for component developers. We need to understand much more about how and why developers are extending our components in order to get the balance right. Making the framework brittle and unevolvable is one the quickest ways I can think of to kill Flex. - Gordon
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Bjorn Schultheiss Sent: Thursday, June 14, 2007 6:39 PM To: [email protected] Subject: Re: [flexcomponents] Re: Private vs Protected On 15/06/2007, at 11:25 AM, reflexactions wrote: For a trully extensible framework that is supposed to form the basis of this whole platform it shouldnt be left that developers need to justify WHY something should be protected, it should be for the framework author to justify WHY something is private. I love it!!! That 'play it safe' line was lame. Use that one for the boss but not for us, the poor devs who might actually need to reference the private member. regards, Bjorn
