I dont think it is realistic to be specific as the problem is general. In any case my view is that the Framework SHOULD be designed to be extensible so inherently everything should be protected unless there is a very very very good reason for it to be private.
I would hate to feel that this problem was going to be resolved API by API as each developer hits up against an issue, thats just a recipe for it never going to be resolved (particularly as we have had 4 different API's in the last 4 years). I would say that ultimately I may end up extending many/most mx controls and as I view it any private declaration is something that may cause me a problem tomorrow, next week, next month. That is a realistic pov as far as I am concerned especially as during this week the first 3 classes I needed to extend all had this issue, and I find it hard to understand how it is "often" possible to get round replacing a protected function that access private vars/function If you want an example take SWFLoader.load, its a public function but it cant be replaced because it accesses the private vars isContentLoaded, brokenImage and _source and calls loadContent which is a private function and another important function to be overridden if you are tyring to do things to the load mechanism. Similarly whne loaded contentLoaded is called as is doScaleContent and doScaleLoader all of which are private leaving you unable to do anything on load until after SWFLoader has already done all the work which may have been a waste of time as you are now going to redo it. I dont want to build fat, non-performant controls, I want and need to build controls that are as light as possible and as effecient as possible so the application they are destined for works well under load. I dont want to have to explain in detail why I need to do this, because as you know often the reason you do "x" is becuase you chose "y" which is becuase of "a" which relates to "b", what I mean is often the decisions are interconnected and it isnt so simple as to say well you can do something else instead as it may impact the whole design. 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. Oh well that enough soap boxing for today lol... tks --- In [email protected], "Gordon Smith" <[EMAIL PROTECTED]> wrote: > > And file an Enhancement for Flex 3 at http://bugs.adobe.com/jira > regarding specific APIs whose privateness is keeping you from doing > something that you need to do. Be sure to explain what you are trying to > do, because often it turns out that there IS a way to do it using public > and protected APIs. > > - Gordon > > ________________________________ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Alex Harui > Sent: Wednesday, June 13, 2007 11:18 PM > To: [email protected] > Subject: RE: [flexcomponents] Private vs Protected > > > > Yup, sorry. From our perspective, anything we make public or protected > has to be supported through the next major release if not longer. So > we're chicken and when we're not absolutely happy with the way we've > coded something we keep it private. > > Which definitely interferes with subclassing for sure, but we want to > play it safe... > > Anyway, if you're really desperate, just copy the source, rename the > class and do what you need. > > -Alex > > ________________________________ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of reflexactions > Sent: Wednesday, June 13, 2007 11:10 PM > To: [email protected] > Subject: [flexcomponents] Private vs Protected > > One thing that has surprised me when looking through the framework > source has been the amount of private var/functions. > > I would have thought that by default they should be protected rather > than private. > > I know you can argue they are private for a good reason, the framework > authors dont want you to access them, BUT in the real world there are > situations which arent so black and white. > > For example there are public or protected functions which I as a > component developer need to override, its easy to do this, then I can > do my work and call super or conversely call super and then do my work. > However there are occasions where what I want to do is to add some code > in the middle of the function, which means I need to replace it. This > is again easy to do until you find the function you are replacing > accesses a private var, then it is impossible to replace the function. >
