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

[Marek Kozieł]

2009/3/24 Alexandre MAKARENKO <alexandre.makarenko at sgcib.com>:
> 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.
> *************************************************************************
>
>


MAJOR DISADVANTAGE(s):
1. Semicolon removed by mistake or forgotten will be real problem here
and can create really deep bugs.
2. Joe have right.

Both are serious and can end with ravishing code analyzing.

-- 
Pozdrowionka. / Regards.
Lasu aka Marek Kozieł

http://lasu2string.blogspot.com/