I can't believe I am actually going to write this. You see, I have probably done more, uhm, `complaining' about the flex framework and the private variables than even I care to remember. With minor exception I have been doing flex component development fulltime in one form or another since Flex 1.
When 2.0 came about and I was suddenly restricted by private variables, I nearly lost it. Back in the 1.5 days, we had a component library of about 120 pieces and already knew that was going to triple going into 2. Not being able to easily extend these classes with private members added almost 200% to our original project cost and I was less than happy. Even today there is still significant cost associated with it and eliminating this practice in favor of protected would allow us to be more effective and productive component developers. All of that said, I do realize and support (now) the mantra that has been put forth by the flex team. Any time a method or property is exposed outside of a class (for this part of the argument there really isn't a difference between public or protected) you have defined an interface. Implicitly you have told developers to use these methods and properties. That is a dangerous door to open as personally I want my components to function on future frameworks and hence I want that interface to stay exactly the same. So, I guess I am personally saying that I believe it is worse for me as a component developer, but better for the Flex community to have stability across releases. Now, truthfully, there really is a long way to go to make this framework component developer friendly and many of the pieces, IMHO, should have some sort of name space option. (P.S. I am not against having to write use namespace SeriouslyThisPartIsGoingToChangeMoron; to get what I need) but that is for another day and another time. I still can't believe I just admitted that, Mike --- In [email protected], Bjorn Schultheiss <[EMAIL PROTECTED]> wrote: > > Fair enough, > > The argument of change has been put forward and i guess that strikes > a cord in most developers. > And Flex 3 is open-sourced and we can do whatever to the SDK, beautiful. > > IMO, the point is quite clear. > Private members kill the idea of a truly extensible framework and > makes component development a pain. > > > my two cents > > Bjorn > > On 15/06/2007, at 12:20 PM, Josh Tynjala wrote: > > > Agreed. > > > > As a component developer, I understand how many of you guys are > > frustrated that it can be difficult to extend the existing Flex > > components. I've been there myself, and it can be time consuming to > > find the right workaround. However, I fully support Gordon's > > reasoning for the private variables and things. > > > > I have a feeling that most custom components built for Flex 2.0.1 > > will be able to easily transition to Flex 3 with only minor > > changes. If all the variables and functions went from private to > > protected or mx_internal, you'll find yourself facing many more > > changes from one version to the next. In fact, it could be much > > worse because such an open architecture might mean that you'll have > > to fully recreate your component from scratch. Right now, I know > > that items that are public or protected probably won't change much > > if at all, and I like that safety. > > > > My two cents. > > > > -Josh > > > > Gordon Smith wrote: > >> > >> 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 OfBjorn 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 > >> > >> > > > > > > > > Regards, > > Bjorn Schultheiss > Senior Developer > > Personalised Communication Power > > Level 2, 31 Coventry St. > South Melbourne 3205, > VIC Australia > > T: +61 3 9674 7400 > F: +61 3 9645 9160 > W: http://www.qdc.net.au > > ((------------This transmission is confidential and intended solely > for the person or organization to whom it is addressed. It may > contain privileged and confidential information. If you are not the > intended recipient, you should not copy, distribute or take any > action in reliance on it. If you believe you received this > transmission in error, please notify the sender.---------------)) >
