PROPOSAL: Lightweight Properties

[David Goodenough]

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