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

[Bruce Chapman]

The naked dot notation is an interesting one. Thank you for sharing the 
idea. But now I want to steal it ;)

One idea that has been floating in the back of my mind relates to a 
syntax for referring to the receiver of a method inside arguments to the 
method.

If we coded such a behaviour using "that" as a keyword analogous to 
"this" (bear with me on this thought exercise) it could look like

x.some().longish().expression().dosomething(that.ACONSTANT, 
that.ANOTHER_CONSTANT)

but we can't really add a new keyword "that", but we could use a "naked 
dot" to mean the same thing.

x.some().longish().expression().dosomething(.ACONSTANT, .ANOTHER_CONSTANT)


or like this with a few semantic tweaks to allow access to static 
methods on the "receiver" of a constructor

Thingamy t = new Thingamy(getBuilder().width(10).height(20).color(.YELLOW));

It wouldn't affect the algorithm for determining which method is 
intended, since the receiver has already been determined.

This might also have value in fluent APIs.

So Please don't specify "naked dot" behaviour until we have explored all 
useful meanings and determined which one has most value.

No this is not intended as a proposal.

Bruce



Alexandre MAKARENKO wrote:
> Naked dot
>
> AUTHOR(S): MAKARENKO Alexandre
> OVERVIEW
> FEATURE SUMMARY: Accessing object fields through unqualified "."
>
> MAJOR ADVANTAGE: Obsoletes attribute naming conventions.
>
> MAJOR BENEFIT:  Makes Java programs visually more readable and eventually 
> less error-prone (see ?Strict mode? in details).
>
> To avoid name collisions and make source codes more maintainable 
> developers either hold with a convention for attribute names or prefix 
> members by ?this.? when refer to. Any naming convention, since not a part 
> of the language, offers only a weak distinction between local variable and 
> object field. Moreover it introduces extra characters and makes the source 
> code not very natural. Using ?this.? is absolutely safe but makes the 
> source code too much heavy. 
> Assessing object fields through unqualified ?.? may be an elegant 
> trade-off between readability and strictness.
>
> MAJOR DISADVANTAGE:  May look assemblish.
>
> ALTERNATIVES:
> Use "this.aField" or m_aField, or _aField, or any other naming convention 
> to distinguish between local variables and object fields.
>
> EXAMPLES
> public class Point
> {
>     public Point( double x, double y )
>     {
>         .x = x; // compiles like this.x = x;
>         .y = y; // compiles like this.y = y;
>     }
>     private double x, y;
> }
>
> DETAILS
> SPECIFICATION: 
> During the name lookup process a package-less ?.? will be considered as 
> ?this.?. So that
> ?.fieldName? will be equivalent to ?this.fieldName?.
>
> COMPILATION: The compiler detects unqualified dots and (if not a start of 
> floating point value) inserts an imaginary ?this?.
>
> TESTING:  Not relevant
>
> LIBRARY SUPPORT: Not relevant.
>
> REFLECTIVE APIS:  Not relevant
>
> OTHER CHANGES: Not relevant
>
> MIGRATION: 
> Weak mode (default). Attribute name look-up is carried out as it is 
> mentioned in the current language specification. For example
> public class Point
> {
>     ...
>     public move( double dx, double dy )
>     {
>         .x += dx; // resolves .x to this.x
>          y += dy; // resolves  y to this.y 
>     }
>     private double x, y;
> }
> Strict mode  (optional). For enterprises who would like to enforce 
> in-house coding styles, there may be a kind of -XStrictMemberAccess 
> compiler option. In this case the unqualified attribute references will 
> fail to compile. For example
>
> public class Point
> {
>     ...
>     public move( double dx, double dy )
>     {
>         .x += dx; // only local and static variables may
>                   // be referred to without ?.? 
>          y += dy; // compile time error: unknown y 
>     }
>     private double x, y;
> }
> COMPATIBILITY
> Ascending source level compatibility (in Weak mode) with existing Java 
> programs.
> Absolute binary compatibility with all existing Java software.
> Disassemblers may produce both ?this.? and ?.? (since they are 
> equivalent).
> REFERENCES
> None
>
> *************************************************************************
> This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.
> Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration.   
> Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or
> falsified.
>                               ************
> Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes 
> par le secret professionnel. 
> Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite.
> Tout message electronique est susceptible d'alteration. 
> La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie.
> *************************************************************************
>
>