PROPOSAL: Lightweight Properties (original) (raw)

David Goodenough david.goodenough at linkchoose.co.uk
Fri Mar 6 02:24:10 PST 2009

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(), 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

More information about the coin-dev mailing list