PROPOSAL: Lightweight Properties
Schulz, Stefan
schulz at e-Spirit.de
Thu Mar 5 14:19:53 PST 2009
> 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
More information about the coin-dev
mailing list