More detail on Property Literals / Property Objects

A little more clarity on my property literal proposal (as it seems to have become named).

The aim is to provide compiler checked access to properties, simplifying the relationship between applications and frameworks. Currently, we write (where person is the bean being worked on):

  binder.bind( person, "surname" );

Property literal syntax replaces this:

  binder.bind( person->surname );

Thus, the arrow operator on a bean returns an object which refers to a specific property on an actual bean instance.

Property literal syntax also allows you to bind to the meta-property, which is the property without a reference to any particular bean instance (where Person is the class name):

  binder.bindMeta( Person->surname );

Finally, there is the possibility of using the same syntax for references to methods:

  binder.bind( person->validate() );
  binder.bindMeta( Person->validate() );

The property can be used by the framework to access the bean in one of these ways (depending on whether you have a property or meta-property - ie. one that is bound or unbound to a specific bean):

  String value = property.get();
  String value = metaProperty.get(beanInstance);

The real question is how to connect these properties to the bean itself. There are two basic ways:

The first is the classical approach, where the PropertyImpl uses reflection to access the get/set methods. In fact, PropertyImpl doesn't even appear in the bean code at all, as it is just generated by the -> operator. So this bean is nothing special at all, all the magic is in the reflection in PropertyImpl.

  public class Person {  // ie. this is a 'normal' bean
    private String surname;
    public String getSurname() { return surname; }
    public void setSurname(String surname) {  this.surname = surname;  }
  }

So this bean is nothing special at all, all the magic is in the reflection in PropertyImpl.

The second approach is much more powerful and OO, but uses more memory.

  public class Person {
    private Property<Person, String> surname =
        new PropertyImpl<Property, String>(this, "surname");

    public String getSurname() {
      return surname.get();
    }
    public void setSurname(String surname) {
      surname.set(surname);
    }
  }

With this structure, the class PropertyImpl can be varied according to what kind of property it is. Thus, if you need a bound property then you simply use BoundPropertyImpl instead.

The classical approach uses less memory, is more proven, and is probably better for the server-side where memory and scalability matter. The second approach requires one object for each property, and probably works better for swing GUIs, which require lots of events to fly about.

For reference, the system at my day-job uses property objects. As we don't have property literals and the arrow operator, we just code-generate lots of methods instead. It has a similar effect, except that only frameworks written by us know about the property objects. As a result, we currently have proprietry frameworks. It would be great if Java could unite around property literals (and method literals?) for interacting between objects, and thus gain the benefts we see in this coding style.