Skip to main content

Pie in the Sky Properties

Posted by cayhorstmann on January 10, 2007 at 12:07 PM PST

The Rules of the Game

???

  • This is just a Gedankenexperiment. I am not seriously
    proposing anything for Java SE7.
  • A property is an abstract thing that has a get and set operation.
  • A "native property" is a "property done right" with new syntax. A
    "JavaBeans property" is what it always was.
  • I don't want to get into any syntax wars. I use an uppercase Pi
    (Π) to denote a property keyword (such as public Π
    int salary) and a lowercase pi (π) to denote property access
    (such as joe π salary). This "pi in the sky" syntax
    is absolutely certain not to get adopted. Substitute your own favorites,
    such as dot, arrow, or whatever.
  • For compatibility, java.beans.Introspector
    includes native properties in BeanInfo.getPropertyDescriptors.
  • Anyone who wrote tools that enumerated get/set
    methods with a mechanism other than java.beans.Introspector
    should go and pound sand.
  • No bleating about "you are destroying encapsulation" and "why don't
    you just make your fields public". The point of a property is to
    encapsulate read/write operations that are deemed essential features of
    a class and whose implementation can evolve over time.

Mangled Methods

The way I understand Jacob's argument is that the get/set naming
convention deserves to be laid to rest as a historical
{accident|mistake|good idea at the time}. Thus, a native property must be
manipulated with the property operator. If you define

public class Employee<br />{
   <tt>public &Pi;</tt><tt> double salary</tt>;
   . . .
}

then you must use

double x = joe &pi; salary;

or

joe &pi; salary += 1000;

You cannot use

double x = joe.getSalary();

or

joe.setSalary(joe.getSalary() + 1000);

Conversely, when translating the expression

x = joe &pi; foo; // never calls getFoo

the compiler would not start hunting for a getFoo
method. If there was no property foo , the expression would
simply be an error.

By default, properties would presumably be implemented as a private
field and a pair of public methods, with mangled names, similar to href="http://www.flex-compiler.lcs.mit.edu/jdk/guide/innerclasses/spec/innerclasses.doc2.html">mangling
in inner classes. For example, 

public class Employee<br />{
   private double $salary;
   public void $salary$set(double);
   public double $salary$get();
   . . .<br />}

The getReadMethod and getWriteMethod of
java.beans.PropertyDescriptor return the Method objects
of these methods, so they can be invoked reflectively in tools.

The href="http://java.sun.com/products/javabeans/docs/spec.html">JavaBeans
specification makes it quite clear that properties are intended for
tools. The GUI builder or the persistence provider has a
legitimate need to access properties that may be different from the needs
of the programmer. Maybe one shouldn't even have a property access
operator? Or should tool properties simply be private?

When you have a private property, the methods would still be generated,
but they are only accessible through introspection (when access control
permits), or as this π property in other methods of the same
class.

Property Annotation Issues

Of course, annotations should be updated to work with native
properties. Something like

@OneToMany
private &Pi; Collection&lt;Choice&gt; choices;

Ideally, a property annotation is associated with the property itself
and not with a method or field. But annotations are placed into the class
files. Do we want to have yet another class file format change that can
express properties and property annotations???

What about compatibility with existing tools and standards? The JPA
annotation processor currently handles annotations of either fields or
getters. Should annotating a property automatically produce a field
annotation? Should there be syntax for moving the annotation to the getter
method instead? Or the other way around???

Stuff that Needs Syntax

The most common use case--a field with a trivial getter and
setter--should require no boilerplate. There need to be various variations
for get-only properties, properties with nontrivial getters and setters,
etc. etc. I don't want to propose syntax for them, so I just tabulate what
needs to be supported with some syntax

Get-only property object π property cannot be an lvalue
Set-only property object π property cannot be an rvalue
Public getter/private getter? Does one want such a fine-grained control, or should the
programmer just supply a private property and a public getter method?
Explicit getter/setter that does something else The programmer supplies a getter/setter that does something else
than just reading or writing the underlying field. For example, a
getter for a name property might concatenate
firstName and lastName. Of course, the method is
still anonymous. For example, something like public &Pi; String name get { return firstName + " " + lastName; }would
produce a method with a mangled name such as $name$get.
Explicit getter/setter that accesses hidden field The programmer supplies a getter/setter that accesses the hidden
field and also does something else, e.g. logging. What is the syntax
for accessing the hidden field?
No field Not all properties give rise to a field, e.g. the name
property described above. Perhaps the compiler should simply see
whether the getter and setter don't access the hidden field?
Bound properties Bound properties fire listeners when the setters are called.
Apparently, they are very important to some people in the Swing world.
href="http://weblogs.java.net/blog/rbair/archive/2007/01/properties_in_j.html">This
blog article discusses some subtleties. I am really muddled about
these. Would users want a separate listener for each property, or a
single listener for all properties of an object? Would it be ok to
synthesize the listener firing method by calling the getter before and
after invoking the setter, or would users want to customize that?
Constrained properties? Constrained properties allow a veto before property changes. These
are really obscure. I have never used them (except for
JInternalFrame, and then only because the API forced me to).
Does anyone care?
Indexed properties? The JavaBeans spec defines array-valued indexed properties with
getter and setter methods for individual elements, but I have never
seen them used in practice.
Property literals? A comment to href="http://www.jroller.com/page/scolebourne?entry=java_7_property_objects">this
article suggests that one might want to pass around a typed
property literal (such as joe π salary) for some purpose,
e.g. querying its capabilities, deferred execution of the
getter/setter, etc.

All of this seems pretty easy to do. The challenge is to come up with
syntax that makes people happy.

Related Topics >>
Blog Links >>