PROPOSAL: Lightweight Properties (original) (raw)

David Goodenough david.goodenough at linkchoose.co.uk
Wed Mar 4 09:31:16 PST 2009


On Wednesday 04 March 2009, Marek KozieĊ‚ wrote:

Hi.

I do not know if I understand you right. MAJOR DISADVANTAGE: - Property names can be dropped (methods not). - Linking naming with code logics. Other proposal that may make yours one unnecessarily: add @ operator (or ^) method@ would return Method object for given method. field@ would return Field object for given field. - This should allow u to write classes u need and make language almost 100% as it is. - It would be faster. - Independend from names. I might be wrong so tell me if I missed something.

I have no problem in extending this to Methods. I just do not have a need for extending it to Methods so I have not considered it.

I also have no problem with simplifying my proposal to generate Field objects, were it possible which I have my doubts about.

The problem with getting Field and Method objects is that you need to be sure that you get the real Field or Method object, and that is difficult as I see it as a result of the way that Field and Method data is stored in class files. They are stored in a binary format and then real Field and Method objects are generated at run time. Correlating that process with the code that the compiler would generate is (I think - please someone prove me wrong) difficult.

It is important that we get to the real Field and Method objects for two reasons. Firstly this mechanism can also be used to find Annotations, which is something currently lacking from the PropertyDescriptor support which returns the Class of the return object from the getter not the Class of the field which means you can not find its annotations. The second problem is that we might want to use the Field object to correlate with the parent object. We can scan the Field array from an object very easily, and I am not quite sure I know the checks that a .equals method would have to do to establish equality when reference identity would do.

David



More information about the coin-dev mailing list