A Non-Proposal related to Properties

[Alan Snyder]

A Non-Proposal related to Properties

This is not a proposal, but it seems related to Properties, so knowing
that there are people on this list who are knowledgeable and care about
Properties, I was hoping to get some useful feedback and suggestions.
(I'll apologize in advance if this is old news...)

As background, I have for a long time been a strong believer in static
type checking and using methods for public access to data. Therefore, many
years ago, when Java and JavaBeans decided to represent each property or
attribute as a get/set method pair, I believed they made a good decision.

However, after spending a year or two applying this approach to large sets
of configuration parameters and winding up with huge interfaces and way
too many wrapper classes, I have changed my mind. It's not that I think
that all get and set methods are bad, but I now believe that dynamic
access to properties is the right way to go in many cases (especially when
there are large numbers of properties and/or an extensible set of
properties, where extension can happen by subclassing or by introducing
new versions of the class). By dynamic access, I mean one get method (or a
small number) and one set method (or a small number) that each take a
parameter identifying the property to get or set.

The only problem is the loss of static type checking. If my code accesses
a specific property (the property identifier is known at compile time), I
want the compiler to type check my code, and I don't want to have to use a
type cast.

Fortunately, there are clever people out there who have figured out a way
to do this using the current Java generics. The basic idea is to define a
class whose instances contain the basic property identifier (a String,
say) along with a class object indicating the type of values that are
acceptable for that property.

Something like this:

public class PropertyName<T>
{
	private String name;
	private Class<T> type;

	public PropertyName(String name, Class<T> type)
	{
		this.name = name;
		this.type = type;
	}

	public String getName()
	{
		return name;
	}

	public Class<T> getType()
	{
		return type;
	}
}

So, for example, if I want to define an integer valued property named
"width", I would write:

	PropertyName<Integer> WIDTH = new PropertyName<Integer>("width",
Integer.class);

Not ideal with that pesky class literal, but the best we can do for now.

Now, using the magic of type inference, one can define a get method that
is statically type checked:

	public <T> T get(PropertyName<T> p);

Here is an example use:

	Integer n = o.get(WIDTH);

where o is defined to support the above get method. No type cast is
required in my program (although one happens under the covers).

This gets me what I want: a simple interface for getting and setting
properties by name, and static type checking when I access properties in a
non-dynamic way.

This idea is obviously not appropriate for COIN because it is too
simple... no language changes required!

My questions:

This idea can be realized with a small set of classes and interfaces. How
would one go about getting them into the JDK? Is someone already doing
this?

What other support would be useful?

One issue is how a class documents the properties that it understands, so
that clients of the class will know what properties can usefully be set
and how they will be interpreted. We could just rely on ad hoc commentary,
but would it be useful to have annotations and/or javadoc constructs that
can make this information available in a better way?