Naked dot - accessing object fields through unqualified "." [C1]

[Reinier Zwitserloot]

'Self-assignment is forbidden' would not be backwards compatibile.  
Yes, such code would most likely be a bug, but its still an issue. It  
would have to be a warning, at best.

However:

Every single external java compiler I know of will warn you when you  
self-assign. Eclipse does it. So does netbeans. So does IDEA. So does  
pmd. So does findbugs.


If you internalize the self-assignment warning, where do you stop?  
There are literally hundreds of 'duh, that must be a bug' warnings you  
could generate. Not all of them are as obvious, or as non-contentious,  
as 'self assignment'. So, where do you stop? Do we use the glacial  
nature of the language changes process to set this up? I say: No. The  
community has done a fine job of addressing these issues by creating  
code checkers. So, I'd instead suggest:

Any improvements to java core in this area should focus on improving  
the ability for external tools to integrate better. For example, a way  
to extend @SuppressWarnings with additional keywords would be great. A  
way to let javac auto-find (via the SPI system) 'warning/error'  
plugins would be another fine idea. Having any kind of plugin system  
for the official javac to give other tools a go at creating warnings  
and errors on the AST that javac's parser is building would be good  
already, using SPI to find these automatically is just one way of  
doing it. I'm not sure APT is quite right for the job; I don't want to  
litter annotations to the gist of '@ExtensivelyCheckMe' all over the  
place.


  --Reinier Zwitserloot



On Mar 29, 2009, at 04:42, Derek Foster wrote:

> The major problem I have with this proposal is that it does not  
> address the point of why I use a prefix on field names. As such, I  
> would still continue to use a prefix even if this proposal were  
> implemented.
>
> In short, I use a prefix to avoid typographical mistakes, like this  
> one:
>
> void setFoo(Thing foob) { // Typo!
>    this.foo = foo;
> }
>
> This will compile, and no warnings are produced, but it ends up  
> assigning foo to itself, which is not what was intended.
>
> Your proposal has exactly the same problem:
>
> void setFoo(Thing foob) { // Typo!
>    .foo = foo;
> }
>
> It therefore does not substitute for a field prefix, which WILL fix  
> the problem:
>
> void setFoo(Thing foob) { // Typo!
>    _foo = foo; // ERROR! Undefined variable 'foo'.
> }
>
> So unless you had some way to make use of the dot prefix mandatory  
> and the only legal way to access fields (which I would like, but  
> which would be an extremely backwards-incompatible change that will  
> never happen in Java), I don't see that adding an optional dot  
> prefix helps the situation except to reduce typing in constructor  
> and setter methods slightly.
>
> (Note: I would love a "self-assignment is forbidden" change to Java.  
> If I have time after my other proposals, I might write one up.  
> (Anyone else want to volunteer? This one is easy!) I might be  
> willing to forego prefixes and use the "this.foo = foo" approach, or  
> even the ".foo = foo" approach, if I was sure it wouldn't cause me  
> to fall into the self-assignment trap.)
>
> Derek
>
>