[Patch] removed deprecated methods and changed variable scope (private-protected) ProjectHelperImpl

[Kev Jackson <ke...@it.fts-vn.com>]

- swapped out deprecated code where the replacement code was obvious - 
left some deprecated methods where I wasn't sure
- changed visibility of class variables from private to protected

still showing 1700+ warnings/errors :(

Kev

Re: [Patch] removed deprecated methods and changed variable scope (private-protected) ProjectHelperImpl

[Peter Reilly <pe...@apache.org>]

Jesse Glick wrote:

> Peter Reilly wrote:
>
>>> OK, I agree that all fields *should* be private, but in these
>>> cases, the fields are in inner classes (I never declare more than
>>> one class in a source file, so I'm not sure that all of these are
>>> inner classes, but bear with me), so the visibility of the field is
>>> restricted to the Class that the inner class is in correct?  And as
>>> such it is actually "private" to other classes even if it's
>>> declared protected.
>>
>>
>> Yes you are correct about the visiblity, however it is not necessary
>> to do this (even if eclipse does whine!).
>
>
> 1. The issue is not so much one particular compiler whining (e.g. PMD 
> also displays the same warning, I think), as that you really are 
> bloating the bytecode a bit by forcing use of a generated accessor 
> method.

Ah, I see. I though that the warning was only an eclipse specific thing.
Since checkstyle does not whine about protected fields in private 
classes, I suppose that
it is ok to do use protected fields in this case.


Peter

>
> 2. What about using package-private access? It should remove the need 
> for a generated accessor, since the legitimate uses (within the same 
> *.java) are certainly within the same package; yet the field does not 
> become visible to clients of the Ant "API" such as custom tasks 
> (unless they are super-evil and declare themselves to be in some Ant 
> package).
>
>> The problem is that there will be a big pile of "good" protected
>> keywords when one is looking for "bad" protected keywords, the rule
>> "no protected fields" is easier to follow than "no protected fields,
>> except where eclipse whines!"
>
>
> Do you really look for the keyword "protected" as such? Wouldn't it be 
> better to examine actual Javadoc, which filters out everything from 
> private nested classes, for example?
>
> -J.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: [Patch] removed deprecated methods and changed variable scope (private-protected) ProjectHelperImpl

[Jesse Glick <je...@sun.com>]

Peter Reilly wrote:
>> OK, I agree that all fields *should* be private, but in these
>> cases, the fields are in inner classes (I never declare more than
>> one class in a source file, so I'm not sure that all of these are
>> inner classes, but bear with me), so the visibility of the field is
>> restricted to the Class that the inner class is in correct?  And as
>> such it is actually "private" to other classes even if it's
>> declared protected.
> 
> Yes you are correct about the visiblity, however it is not necessary
> to do this (even if eclipse does whine!).

1. The issue is not so much one particular compiler whining (e.g. PMD 
also displays the same warning, I think), as that you really are 
bloating the bytecode a bit by forcing use of a generated accessor method.

2. What about using package-private access? It should remove the need 
for a generated accessor, since the legitimate uses (within the same 
*.java) are certainly within the same package; yet the field does not 
become visible to clients of the Ant "API" such as custom tasks (unless 
they are super-evil and declare themselves to be in some Ant package).

> The problem is that there will be a big pile of "good" protected
> keywords when one is looking for "bad" protected keywords, the rule
> "no protected fields" is easier to follow than "no protected fields,
> except where eclipse whines!"

Do you really look for the keyword "protected" as such? Wouldn't it be 
better to examine actual Javadoc, which filters out everything from 
private nested classes, for example?

-J.

-- 
Jesse Glick <ma...@sun.com> x22801
NetBeans, Open APIs  <http://www.netbeans.org/>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: [Patch] removed deprecated methods and changed variable scope (private-protected) ProjectHelperImpl

[Peter Reilly <pe...@apache.org>]

Kev Jackson wrote:

>
>> We will not be changing private to protected.
>> As much as possible all fields should be private and there should
>> be very few protected methods.
>> For current released code, it is not possible to change protected fields
>> to private fields due to BC consideration.
>>
>
> OK, I agree that all fields *should* be private, but in these cases, 
> the fields are in inner classes (I never declare more than one class 
> in a source file, so I'm not sure that all of these are inner classes, 
> but bear with me), so the visibility of the field is restricted to the 
> Class that the inner class is in correct?  And as such it is actually 
> "private" to other classes even if it's declared protected.

Yes you are correct about the visiblity, however it is not
necessary to do this (even if eclipse does whine!).
The problem is that there will be a big pile of "good" protected keywords
when one is looking for "bad" protected keywords, the rule "no protected 
fields"
is easier to follow than "no protected fields, except where eclipse whines!"

Peter

>
> Or have I got my visibility/scope rules muddled.
>
>>>
>>> still showing 1700+ warnings/errors :(
>>
>>
>>
>> but it is coming down! 8-)
>
>
> Slowly, very slowly!
>
> Kev
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: [Patch] removed deprecated methods and changed variable scope (private-protected) ProjectHelperImpl

[Kev Jackson <ke...@it.fts-vn.com>]

> We will not be changing private to protected.
> As much as possible all fields should be private and there should
> be very few protected methods.
> For current released code, it is not possible to change protected fields
> to private fields due to BC consideration.
>

OK, I agree that all fields *should* be private, but in these cases, the 
fields are in inner classes (I never declare more than one class in a 
source file, so I'm not sure that all of these are inner classes, but 
bear with me), so the visibility of the field is restricted to the Class 
that the inner class is in correct?  And as such it is actually 
"private" to other classes even if it's declared protected.

Or have I got my visibility/scope rules muddled.

>>
>> still showing 1700+ warnings/errors :(
>
>
> but it is coming down! 8-)

Slowly, very slowly!

Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: [Patch] removed deprecated methods and changed variable scope (private-protected) ProjectHelperImpl

[Peter Reilly <pe...@apache.org>]

Kev Jackson wrote:

> - swapped out deprecated code where the replacement code was obvious - 
> left some deprecated methods where I wasn't sure
> - changed visibility of class variables from private to protected

We will not be changing private to protected.
As much as possible all fields should be private and there should
 be very few protected methods.
For current released code, it is not possible to change protected fields
to private fields due to BC consideration.

>
> still showing 1700+ warnings/errors :(

but it is coming down! 8-)

Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org