Name: rmT116609			Date: 05/01/2003


A DESCRIPTION OF THE REQUEST :
Encapsulation is a good thing, but leads to unnecessary verbosity:

thing.setCount(thing.getCount() + 1);

where you would rather write the much clearer:

thing.count++;

Suppose the count attribute is private, but public getters and setters are present.  The compiler could easily detect this and generate the required method calls.  This could also be done when private fields are accessed internally within the defining class, leading to more robust code when additional behavior is required later.

However, there are cases where you would actually want to directly access member fields.  For example, within the defining class, such as the actual getter and setter implementations, but also in those rare situations where execution speed is critical.  I propose a new notation if you really need direct acccess, by prefixing the member name with '@':

@count++;

The compiler will then generate code the same as before.  Thus, full encapsulation will automatically become the rule, and direct field access will become the exception.

Taking this a bit further, the compiler could also automatically generate getters and setters for non-private member fields, using the access specifier used for the field.  The compiler will then make the member field private (although this may break backward compatibility).  If you don't want this behavior, just provide the appropriate getters and setters with the needed access specifiers yourself, and the field access will not be changed.  Likewise, fields can be made immutable by providing a (possibly empty) private setter.

JUSTIFICATION :
The proposal not only leads to shorter, much clearer code, but will also make full encapsulation the default, leading to more robust code.
(Review ID: 184818) 
======================================================================