Namespace checks are done in the compiler, regardless if they are private, protected or public. That shouldn't impact performance.
The real problem is the assumption when a private function is created. Protected and Public functions are under the assumption that the user will give incorrect data and the data needs to go through sanity checks / bounds checks / etc. Private methods are written under the assumption that the parameters are clean and won't do bad things. Private functions are also under documented, so users are more apt to send in bad data or use them incorrectly. -Nick On Mon, Mar 31, 2014 at 7:57 AM, 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 >
