Naked dot - accessing object fields through unqualified

[Reinier Zwitserloot]

You can think what you want, but that's not likely. Again, a source  
keyword would open up an opportunity to engage a bunch of strict  
checks, but you underestimate the amount of code that people have  
inherited from people that inherited it from people that inherited it,  
and each added their own little mess to the spaghetti. Them, and a  
bunch of contractors in between. It was thoroughly tested somewhere in  
1999, and nobody even knows how it works, but every so often someone  
does need to wade into the mess and fix something.

You can not force these people to deal with a gazillion 'these are  
likely bugs' errors. It needs to be opt-in.


Your further suggestions are even further off the mark; why is an  
abstract class with a private constructor bad? It's a matter of style;  
most people who want utility classes make their constructors final,  
but some make their class abstract as well, because of the link  
between 'abstract' classes (cannot be instantiated) and utility  
classes (should not be instantiated). I believe a programming language  
should set style as much as possible, but java doesn't do that now,  
and changing it is a massive turn-around in java dogma that you or I  
just cannot take.

C style array declarations - okay, fine. Yes. Guuuuhhhh, they are  
making working with the [ and ] symbols in a way that doesn't screw up  
the parser annoying, to say the least. Yet another argument for a  
'source' keyword.


If people don't want to listen to or setup their warnings, then more  
errors is just not going to help. Your suggestion is: Some companies  
are so boneheaded they won't listen to their IDE's warnings, so we'll  
just force it on them with a javac change? Nononono. That'll just  
result in them not updating their java, and that's one of those things  
sun (rightfully) wants to avoid like the plague without a solid reason  
to do it (like wiping the slate clean across the board, not just in  
this niche area).

At any rate, there's no way to centralize errors/warnings in javac.  
Period. They are far too contentious. As I have said before, APT is a  
good start, but some more support for external warning/error plugins  
would help (including the ability to add more SuppressWarnings  
keywords). It would be nice if javac shipped out of the box with an  
extensive set, sure, but, again, opt-in.





  --Reinier Zwitserloot



On Apr 3, 2009, at 09:04, Derek Foster wrote:

> Replies inline.
>
> -----Original Message-----
>> From: Reinier Zwitserloot <reinier at zwitserloot.com>
>> Sent: Mar 31, 2009 9:03 AM
>> To: Derek Foster <vapor1 at teleport.com>
>> Cc: coin-dev at openjdk.java.net
>> Subject: Re: Naked dot - accessing object fields through  
>> unqualified "." [C1]
>>
>> '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.
>
> Personally, I think it should be an error, since there seems to be  
> no valid reason to do it, and it almost certainly indicates a bug. I  
> think that compilers should default to being in a 'strict' mode  
> where things like this that have been found to be bad ideas with  
> virtually no upside are treated as illegal, even if that makes them  
> not fully backwards compatible. For backwards compatibility, there  
> could be a command-line switch to turn off strict mode if necessary  
> for compiling old code.
>
> Some other things I'd like to see in this category:
>
> * Having an abstract class with a constructor that has 'public' or  
> 'private' access.
>
> * Using C-style array declarations. (int x[] instead of int[] x)
>
> I could probably think of a few more.
>
>> 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.
>
> Mere warnings are not enough to stop people from doing this sort of  
> thing, especially when the warning message is buried in 436 other  
> warning messages about code which is less unambiguously broken than  
> this is. (Note: I *HATE* it when people ignore compiler warnings  
> like this, but I am speaking from experience when I say that it  
> usually takes years to convince a company to clean up its act.)  
> Unfortunately, I have worked for lots of companies that routinely  
> ignore warnings.
>
>> 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 think that when a practice is almost always problematic, is easy  
> to fix, and has no legitimate purpose (and/or has an easy workaround  
> in the few cases that it is legitimate), it should be made an error  
> (with the caveats above). I don't think that we should carry along  
> every single design mistake in the 1.0 edition of the Java Language  
> Standard with us until the end of time. The ability to achieve  
> backwards compatibility is important (hence the ability to turn off  
> strict mode I described above), but clarity of language design and  
> preventing common errors is too. Otherwise, the amount of code which  
> contains the error in question just keeps growing over time.
>
>> I say: No. The
>> community has done a fine job of addressing these issues by creating
>> code checkers.
>
> In my experience, the community, by and large, does not use code  
> checkers. Relatively few companies do. Again, I wish it were  
> otherwise, but the truth is that most companies assume that if  
> something passes the checks done by the compiler, it's probably  
> fine. Having tried to introduce them into companies a few times, I  
> can report that most software engineers really don't want to be  
> bothered with them (and are convinced that checkers won't find any  
> bugs important enough to justify the time spent learning to use them  
> and cleaning up lots of innocuous warnings just for the sake of the  
> tool). Again, I thoroughly disagree with that philosophy, but that's  
> what I have heard repeatedly in industry.
>
> Also, using a code checker is often a painful experience if you are  
> forced to use a framework written by people who don't use them.
>
> The other issue is that every code checker checks for a different  
> set of things. Just because your code passes your code checker's  
> rules doesn't mean it will pass mine, or vice versa. The Sun Java  
> compiler as of a specific version, at least, is the same for  
> everybody.
>
>> 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.
>
> I'm certainly in favor of making life easier for code checkers.  
> However, checkers that don't get used are no better than ones that  
> don't exist. Javac (or jikes, etc.) gets used every time someone  
> compiles a program. That means it's going to have far more influence  
> on the correctness of the majority of Java code than any other tool.
>
> Derek
>
>>
>>
>> --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
>>>
>>>
>>
>