When there is doubt regarding performance, Jackson Dunstan probably has the answer[1] :) I also agree that we should take care of those pesky private methods case by case.
[1] http://jacksondunstan.com/articles/1820 On 31 March 2014 12:57, Maurice Amsellem <maurice.amsel...@systar.com>wrote: > 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 > -- João Fernandes
