I am not sure of that , but it might be that private methods execute faster than protected ones (because the resolution can be done at compile time). So turning every private method to protected might have an impact on performances.
Needs confirmation from someone who has a deep knowledge on AS3 execution in the Flash Player. Maurice -----Message d'origine----- De : Konstantin Elstner [mailto:f...@dashart.de] Envoyé : lundi 31 mars 2014 13:18 À : dev@flex.apache.org Objet : Time for refactor? Reworking the annoying private methods Hi, for me as Flex developer it is very annoying to find a problem / bug in the current Flex versions. In the most case I analyze the problem / bug and then I find the "source" of the problem, but I can not integrate a workaround, because the method which is responsible has a private scope. Current example: private function hideScrollBars():void { ... } from spark.components.Scroller. I waste so much time to create some dirty workarounds around simple private methods in many components. So very often, I am asking myself ... why is this method private, it could be protected and I could create a simple fix. Also it would more simple to create a patch for bugs, or implement new custom functions and commit it back to. So my rhetoric question: Is is time to restructure / rework and revalidate every as private declared method and variable in the Flex sources? All this private usages has a taste for me, like the Adobe guys which initial created the classes do not completely understand the concept of mx_internal / private / protected and public scopes ;) Konstantin
