More methods also increases the size of the documentation and forces us to consider backward compatibility when changing it.
But there is nothing stopping you from providing a patch that changes an API's visibility. I would not want to do "all of them". -Alex On 3/31/14 6:24 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >I forgot about it, thanks. > >So private and protected basically the same ( 56 and 57 ms) > >Maurice > >-----Message d'origine----- >De : João Fernandes [mailto:joaopedromartinsfernan...@gmail.com] >Envoyé : lundi 31 mars 2014 15:08 >À : dev@flex.apache.org >Objet : Re: Time for refactor? Reworking the annoying private methods > >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
