PROPOSAL: Lightweight Properties

[David Goodenough]

On Friday 06 March 2009, Schulz, Stefan wrote:
> > In effect the Property class becomes the generified Field
> > object, so that
> > problem is circumvented.
>
> Well, the generified Field object should be returned by the reference, so
> that the generic type can be retrieved at compile-time, otherwise it would
> not make much sense. That's why the example uses the factory method
> at(<last part of the chain>), otherwise it will be difficult to have
> compile time type safety.
>
> > 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.
>
> You are right. I forgot about the correctness of the chain. And this will
> only be possible by a new notation.
If the FCM could be extended to produce a Field array if there was a chain
that would be a good solution to this problem (see my other response).
>
> > 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.
>
> I don't understand this one. You won't annotate the Field class but the
> field, so the object returned will have to support Annotation retrieval, I
> guess.
This concern arised from a problem with PropertyDescriptors.  If you get
a PropertyDescriptor for a field, and ask for its Type, the Class that is 
returned is the Class of the return object from the getter rather than the
Class of the actual field.  This means that you can not get access to 
any annotations that have been declared on the field.  What I was worried
about was that this mechanism might construct a Field object, rather than
returning the real Field object held in the containing class, and thus be
subject to the same problem.  Sorry if I was unclear (I may still be unclear).
>
> > 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.
>
> FCM won't. But maybe a proposal for Field-Literals might have a chance, as
> it seems a coin to me. Not much magic about it, I think. But then again, I
> might miss the hard parts as I have no real insight into javac etc.
Well I have started to work on that.  I hope to have at least a first cut 
next week although it is making my head ache a bit.  On second (or it is
third) reading, the documentation I have found is making more sense than
it did the previous times.
>
> @Joe: Would it make sense to file a proposal on Field-Literals or would it
> be doomed right away? And I am not sure, whether completing such a proposal
> by Method- and Constructor-Literals would become too big for Coin. Any
> hint?
I would be quite happy to reduce my proposal to just Field Literals.
>
> Further, I am not sure, how elaborate I could do it by myself, too, so any
> coop is welcome. Sorry, for getting off topic.
>
> Cheers, Stefan

David