Re: Time for refactor? Reworking the annoying private methods
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" 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
>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
Re: Time for refactor? Reworking the annoying private methods
Hi, I will optimize my code in the next days. Afterwards I open a ticket in JIRA and contribute the patch file. Best wishes Konstantin
Re: Time for refactor? Reworking the annoying private methods
Hi, > In the meantime the good old monkey patch style saved me from more trouble > with the Scroller components, Anything you do find please raise a JIRA for it so at least we know about about and can hopefully fix it - we'd like to get to the state were there no need for any monkey patches but can;t do that if people don't report them. Thanks, Justin
Re: Time for refactor? Reworking the annoying private methods
Hi again, thanks for the input about that ;) There are good reasons against are a complete refactoring, looking especially on 3rd party code. And it is large task to refactor code afterwards *hrm. So it would be great to remove the private methods case by case like Jackson Dunstan said. In the meantime the good old monkey patch style saved me from more trouble with the Scroller components, (thx to Tom for the hint). Currently I am working on a Touch / Mouse interactive mode switch for a Desktop AIR app, and there popped out some misbehaviors on switching of the interactive mode at runtime.
RE: Time for refactor? Reworking the annoying private methods
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 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
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 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
Re: Time for refactor? Reworking the annoying private methods
On 31/03/14 12:17, Konstantin Elstner wrote: Is is time to restructure / rework and revalidate every as private declared method and variable in the Flex sources? I think it's a lot better to go case by case; in theory as soon as a method isn't private it needs adding to the tests. You can always monkey patch your way around the issue in the mean time. Tom
Re: Time for refactor? Reworking the annoying private methods
Hi, > 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. Also true for a lot of public functions as well. Justin
Re: Time for refactor? Reworking the annoying private methods
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
>
Re: Time for refactor? Reworking the annoying private methods
Hi, IMO some things should be kept private, but I agree in Flex too much is private, we can look at them on a one by one basis. Every time we make something private protected we risk breaking 3rd party code if there a name collision so need to take a little care. Thanks, Justin
RE: Time for refactor? Reworking the annoying private methods
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
