Just to bring up one reason why we decided not to make all privates mx_internal, the AS compiler and VM can do optimizations on private members that it sometimes can't do when a member is namespaced. I don't know that we've done any real comparisons, but we expect that the performance of the framework would degrade were we to eliminate private. I'm not saying we won't investigate it further, but just so you realize we certainly considered it. Matt
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Smith Sent: Thursday, June 14, 2007 8:45 PM To: [email protected] Subject: RE: [flexcomponents] Re: Private vs Protected > dare I suggest it seems they only are protected when adobe needed to do so > in order to create there own subclassed components. Sure you can suggest it, and it's basically true... the only components that most of us developers on the Flex team have developed are the ones in the framework! It's outside developers like you that do the extending, and you run into problems that we didn't consider. That's why we're asking for specifics about the problems you're encountering so that we can make you happy while keeping the framework flexible. - Gordon ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of reflexactions Sent: Thursday, June 14, 2007 8:27 PM To: [email protected] Subject: [flexcomponents] Re: Private vs Protected Personally the idea of people using the open source framework to role there own version of it troubles me. With framework caching now a reality, the last thing I as a component developer want is to release components based on a frame work only to find at run time that the framework isnt the one I designed the component against or some such related issue. I also dont want to role my own version of the framework and then be in the business of supporting it for all the people who use my component, thats adobes job. I dont mind creating different versions of my component to work with different official versions of the framework but I do mind if it becomes a complete free for all. FYI As a "measure" of the size of the problem, there are 2000 private vars in the framework and only 128 protected var. Functions are more balanced with a 1000 of each (though mostly they are overrides), dare I suggest it seems they only are protected when adobe needed to do so in order to create there own subclassed components. --- In [email protected] <mailto:flexcomponents%40yahoogroups.com> , 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:flexcomponents%40yahoogroups.com> > >> [mailto:[email protected] <mailto:flexcomponents%40yahoogroups.com> ] On Behalf OfBjorn Schultheiss > >> Sent: Thursday, June 14, 2007 6:39 PM > >> To: [email protected] <mailto:flexcomponents%40yahoogroups.com> > >> 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 <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.---------------)) >
