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

alexandre.makarenko at alexandre.makarenko at
Tue Mar 31 14:37:32 PDT 2009

First, this story is not about IDEs, this story is about Java!!!

Second, this is not about fat-finger bugs and not about how tomorrow tools will replace developer's brain ...
If you look at all possible troubles one can in with Java today, you will never ever write a single line of code.

Now, what is the true reason of this proposal.


I DO NOT use 'this.' since it completely destroys the nicest notion of scope and context (a part of the object oriented paradigm). By putting 'this.' one makes the compiler's job and a Java code looks like using an old style pointer to C structure all over the program (like Python's self?). It does not prevent developers from bugs neither...

Ask a Java developer who uses 'this.' why he/she does so... There will be 3 answers (fix me if I'm wrong)
- it is less error-prone (a developer with 6-month experience)
- Eclipse puts it automatically (somebody who does not like his job, who types all the day 'this.' followed by Ctrl+Space to see what is on the menu...)
- it makes the code more readable

Now about the last point. Actually it makes the line you are looking at more readable and not the entire program. This is the point. Today people (not all) start to believe that a code is to be looked at. I think a computer program is to be read like a book (since it is written by humans for humans). With this regard 'this.' is not a friend.

>From this point of view using 'Naked Dot' is not much different from 'this.' (unless in the 'Strict mode' as mentioned in the proposal). My hope was to save my eyes from that heavy looking programs making my brain to parse the code and not to read it fluently.

Sincerely yours

----- Original Message -----
From: "Marek Kozieł" <develop4lasu at>
To: "Derek Foster" <vapor1 at>
Cc: coin-dev at
Sent: Tuesday, March 31, 2009 3:31:13 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: Naked dot - accessing object fields through unqualified "." [C1]

2009/3/29 Derek Foster <vapor1 at>:
> 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!
> = 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'.
> }

You can use:
Eclipse -> Java -> Code Style -> Edit -> Member Access -> Use 'this'
qualifier for field access. (Always)

> 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 " = 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

     class Bar {
          public String     name;
          public Bar          right;

     class Root {
          public Bar     right;
          public Bar     left;

          public Root(Bar right, Bar left) {
               this.left = left// left is set here
               .right = right;


Did you noticed missing semicolon?

Pozdrowionka. / Regards.
Lasu aka Marek Kozieł

More information about the coin-dev mailing list