Pull request to make private methods static when they are plain functions

[John Wagenleitner <jo...@gmail.com>]

About to merge in PR 290 [1] and wanted to do a quick poll to see if there
were any objections since it touches quite a few files across core and
sub-modules.  Any objections to merging this into master?  And GROOVY_2_4_X?

[1] https://github.com/apache/groovy/pull/290

Re: Pull request to make private methods static when they are plain functions

[Jochen Theodorou <bl...@gmx.org>]

If a method is so big, that you can no longer see if a local 
variable/parameter is changed or not, then the method needs refactoring, 
not the variables a modifier. So I see no need for adding this, unless 
you want to express something by this.

bye Jochen

On 28.04.2016 02:11, John Wagenleitner wrote:
>
>
> On Sun, Apr 24, 2016 at 11:13 PM, Mario Garcia <mario.ggar@gmail.com
> <ma...@gmail.com>> wrote:
>
>     +1
>
>     Besides, I was wondering If most, if not all these static methods,
>     should have all parameters marked as final. Is there any policy
>     about this ? Would it help ?
>
>
>
> I don't think there's a policy, personally I tend to not use final for
> local/parameters unless it's used in an anonymous inner class.
> Hopefully the methods are short enough that the extra syntax is not
> needed to know if it reassigned or not.
>
>
>     2016-04-24 21:46 GMT+02:00 Jochen Theodorou <blackdrag@gmx.org
>     <ma...@gmx.org>>:
>
>         On 24.04.2016 18 <tel:24.04.2016%2018>:12, John Wagenleitner wrote:
>
>             About to merge in PR 290 [1] and wanted to do a quick poll
>             to see if
>             there were any objections since it touches quite a few files
>             across core
>             and sub-modules.  Any objections to merging this into
>             master?  And
>             GROOVY_2_4_X?
>
>             [1] https://github.com/apache/groovy/pull/290
>
>
>         I guess it is ok. I did see two package private methods made
>         private instead of only private ones, but even those should be
>         ok. so unless I did oversee something I do not really have any
>         objection here.
>
>         bye Jochen
>
>
>

Re: Pull request to make private methods static when they are plain functions

[Mario Garcia <ma...@gmail.com>]

Thanks for the clarification :)
On 28 Apr 2016 02:12, "John Wagenleitner" <jo...@gmail.com>
wrote:

>
>
> On Sun, Apr 24, 2016 at 11:13 PM, Mario Garcia <ma...@gmail.com>
> wrote:
>
>> +1
>>
>> Besides, I was wondering If most, if not all these static methods, should
>> have all parameters marked as final. Is there any policy about this ? Would
>> it help ?
>>
>
>
> I don't think there's a policy, personally I tend to not use final for
> local/parameters unless it's used in an anonymous inner class.  Hopefully
> the methods are short enough that the extra syntax is not needed to know if
> it reassigned or not.
>
>
>>
>> 2016-04-24 21:46 GMT+02:00 Jochen Theodorou <bl...@gmx.org>:
>>
>>> On 24.04.2016 18:12, John Wagenleitner wrote:
>>>
>>>> About to merge in PR 290 [1] and wanted to do a quick poll to see if
>>>> there were any objections since it touches quite a few files across core
>>>> and sub-modules.  Any objections to merging this into master?  And
>>>> GROOVY_2_4_X?
>>>>
>>>> [1] https://github.com/apache/groovy/pull/290
>>>>
>>>
>>> I guess it is ok. I did see two package private methods made private
>>> instead of only private ones, but even those should be ok. so unless I did
>>> oversee something I do not really have any objection here.
>>>
>>> bye Jochen
>>>
>>
>>
>

Re: Pull request to make private methods static when they are plain functions

[John Wagenleitner <jo...@gmail.com>]

On Sun, Apr 24, 2016 at 11:13 PM, Mario Garcia <ma...@gmail.com> wrote:

> +1
>
> Besides, I was wondering If most, if not all these static methods, should
> have all parameters marked as final. Is there any policy about this ? Would
> it help ?
>


I don't think there's a policy, personally I tend to not use final for
local/parameters unless it's used in an anonymous inner class.  Hopefully
the methods are short enough that the extra syntax is not needed to know if
it reassigned or not.


>
> 2016-04-24 21:46 GMT+02:00 Jochen Theodorou <bl...@gmx.org>:
>
>> On 24.04.2016 18:12, John Wagenleitner wrote:
>>
>>> About to merge in PR 290 [1] and wanted to do a quick poll to see if
>>> there were any objections since it touches quite a few files across core
>>> and sub-modules.  Any objections to merging this into master?  And
>>> GROOVY_2_4_X?
>>>
>>> [1] https://github.com/apache/groovy/pull/290
>>>
>>
>> I guess it is ok. I did see two package private methods made private
>> instead of only private ones, but even those should be ok. so unless I did
>> oversee something I do not really have any objection here.
>>
>> bye Jochen
>>
>
>

Re: Pull request to make private methods static when they are plain functions

[Mario Garcia <ma...@gmail.com>]

+1

Besides, I was wondering If most, if not all these static methods, should
have all parameters marked as final. Is there any policy about this ? Would
it help ?

2016-04-24 21:46 GMT+02:00 Jochen Theodorou <bl...@gmx.org>:

> On 24.04.2016 18:12, John Wagenleitner wrote:
>
>> About to merge in PR 290 [1] and wanted to do a quick poll to see if
>> there were any objections since it touches quite a few files across core
>> and sub-modules.  Any objections to merging this into master?  And
>> GROOVY_2_4_X?
>>
>> [1] https://github.com/apache/groovy/pull/290
>>
>
> I guess it is ok. I did see two package private methods made private
> instead of only private ones, but even those should be ok. so unless I did
> oversee something I do not really have any objection here.
>
> bye Jochen
>

Re: Pull request to make private methods static when they are plain functions

[Jochen Theodorou <bl...@gmx.org>]

On 24.04.2016 18:12, John Wagenleitner wrote:
> About to merge in PR 290 [1] and wanted to do a quick poll to see if
> there were any objections since it touches quite a few files across core
> and sub-modules.  Any objections to merging this into master?  And
> GROOVY_2_4_X?
>
> [1] https://github.com/apache/groovy/pull/290

I guess it is ok. I did see two package private methods made private 
instead of only private ones, but even those should be ok. so unless I 
did oversee something I do not really have any objection here.

bye Jochen