PROPOSAL: Lightweight Properties

David Goodenough david.goodenough at
Fri Mar 6 02:10:38 PST 2009

On Friday 06 March 2009, David Goodenough wrote:
> 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.
> David

As a further thought, I don't suppose there is any chance of changing
FCM slightly to have Foo#bar#ali produce a Field array?  The simple case can 
continue to produce a single Field and the PropertyBuilder can have
overloaded methods.  That would get around the checkability problem.


More information about the coin-dev mailing list