flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Time for refactor? Reworking the annoying private methods
Date Sun, 06 Apr 2014 02:20:24 GMT
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.amsellem@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:joaopedromartinsfernandes@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.amsellem@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:flex@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


Mime
View raw message