Take this message as a blog, thought, discussion, or really whatever you feel like it should be, but I felt this should dually be noted some where within a Flex community and what better place than here. This is a bit of a vent, or more like a "why did they do it this way"...so take it as you please.
In my past, I feel that I've had the most trouble with Flex in subclassing to get my components exactly how I want them. Mainly because some components are up to the neck in private variables/functions that simply overriding the class becomes an entirely new component that's copy and pasted (bad, very bad!) to work or look a certain way and hoping that you don't get runtime errors.
For example, MenuBars are up to the teeth in private properties/functions. The class has this dreaded private variable MARGIN_WIDTH which tags about 10 pixels of extended menubar to the ends for some reason... To actually get rid of it, you have to recreate the variable and with that comes copy and pasting the measure and updateDisplay methods.
My job persists that we develop an application that is aesthetically appealing and different. I very well agree with them and it's very rewarding to get it to work. But hacking components to death, isn't really a long term goal if this SDK flips over like it did from AS2 to AS3. I think most visual components should inherently have Protected all over the place instead of Private. What are your thoughts?
I came across a discussion within a Yahoo group that clarified more on why so many components are kept private and it's tagged below, definitely worth a read.
I think what he is referring to is that within the Adobe Framework it
is standard practice to declare event handlers in a component as
When you (as a component developer) come to subclass the component
and need to override the event handling functionality of the super
class you cant as the handler is private. You can add another handler
for the same event which is very ineffecient but in any case you cant
stop the superclass handler from executing.
The only exceptions to handlers being private rule seems to me where
other Adobe dev's needed to extend a particular class and bumped in
to this very same issue so they went and changed that particular
super class handler to protected, lucky them!
i.e in the framework there are 7 private and 1 protected
mouseOverHandlers, the 1 being ListBase obviously where the DataGrid
and Tree developer found they needed to override it.
and to be honest, as I have said before, the "report this one
function/var at a time" is unworkable/impractical, it needs someone
at Adobe to take a fresh look at the whole framework from the
perspective of a component developer. Yeah I understand component
developers represent an insignificant blip on the radar (though maybe
thats because the framework is so difficult to extend in the first