If you want to say that we shouldn't rely on needing access to any private variables, it's only a small difference to say it's OK to rely on mx_internal variables. The internal vars are marked as such because they might change in future releases. So if the objection is that your code might break because Adobe releases updates to the framework class you're using, then the same problem exists if you use the mx_internal vars.
And I agree, Adobe made design choices about what you should need access to when you are extending components. This means they run into some of the same coding problems if they were to try to subclass these classes as well. But all that means is that Adobe can't make the extensions that we also can't make. And let's remember that the choices made by the Adobe flex framework team are just choices made by other programmers (albeit some damn good ones), but fallible programmers nonetheless. They try to anticipate what will be needed to make powerful extensions of components. But it's hard to look down the road and figure out what people will want to do. And often there is a workaround that can accomplish what you need without accessing private vars or methods. I've gone this route as well many times. But I think that it's not accurate to say that there is always a solution like this. And even if you can get it to work, sometimes you end up with such a convoluted solution, and you have to do much more processing work (removing child components that were added, intercepting events dispatched and stopping or redispatching...) which opens the door to more bugs. So obviously it's a double-edged sword to ever copy-paste framework classes. I guess it's just my personal opinion that it can be well worth it. Doug On 2/22/07, EECOLOR <[EMAIL PROTECTED]> wrote:
>you need access to a handful of private variables and functions in the parent class I have extended quite some components aswell. What i found out however, was that in the en i most of the time did not need those private variables and methods. At the end of a day full of fiddling i found a variable or method within the mx_internal namspace (which is publicly available). So now when i need to extend something i make sure i check all definitions of mx_internal first. Greetz Erik
