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>]

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