ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <peterrei...@apache.org>
Subject Re: [Patch] removed deprecated methods and changed variable scope (private-protected) ProjectHelperImpl
Date Mon, 13 Dec 2004 17:43:24 GMT
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


Mime
View raw message