PROPOSAL: Lightweight Properties

David Goodenough david.goodenough at
Fri Mar 6 01:47:22 PST 2009

On Thursday 05 March 2009, Schulz, Stefan wrote:
> > I do not see (maybe I did not understand FCM) how I could handle
> > foo#bar#ali.  In this case you need a Field array, not just a field.
> > Additionally the FCM case only seems to handle the Foo#bar case,
> > not the foo#bar case.  That is not the end of the world - it would work
> > in the examples I need, but it is less than my proposal covers.
> Field literals as defined by FCM are meant to ease access for reflection.
> There was no further intent, AFAIR, as to have an analogue to Method
> literals. As the result is a Field instance, chaining does not make sense.
> Literals are only defined on types not instances.
> I'm not sure about autoconverting foo#bar to some Property instance. The
> main goal, as far as I understood, is to have compile time checks on
> accessing properties instead of using Strings. Not sure, if this helps, but
> just to note down the thought:
> As a prerequisite, we might need a generified Field class (not necessarily
> has to be the java.reflect.Field class). Now assuming Foo having a field
> bar of type Bar, and Bar having a field baz of type Baz. Using (generified)
> Field literals, one could create a property builder taking Fields instead
> of Strings as parameters, e.g.:
> Property<Foo, Bar> p1 = PropertyBuilder.on(Foo.class).at(Foo#bar);
> Property<Foo, Baz> p2 =
> PropertyBuilder.on(Foo.class).via(Foo#bar).at(Bar#baz); Property<Foo, Bar>
> p3 = PropertyBuilder.on(foo).at(Foo#bar);
> Property<Foo, Baz> p4 = PropertyBuilder.on(foo).via(Foo#bar).at(Bar#baz);
> I admit, this does not look as neat, but would serve the purpose. Or am I
> missing the target?
> Cheers,
> Stefan

Yes it would server the purpose, and frankly ease of use is trumped by 
desparate need so I am happy to take any compiler checkable solution
that works.

In effect the Property class becomes the generified Field object, so that
problem is circumvented.

The only thing it can not do is to check that the chain is correct (i.e in the 
example above that Foo#bar is a Bar( at compile time.  When the 
PropertyBuilding is building the Property  it can, but that is a little later
than I would like - but still a great improvement on evalutation time, added
to which the chained case is a minority case.

My only question concerns annotations.  It is important that the Field object
is the real one, and not a synthetic partial copy.  The reason for this is 
so that I can access Annotations.  If this will work then I am happy.

So if FCM is going to be in -7 then my proposal is unnecessary.  But of course
that makes an assumption and unless I have missed something it seemed
to be as far off as Property support.


More information about the coin-dev mailing list