For further consideration...

[David Goodenough]

On Tuesday 31 March 2009, Mark Thornton wrote:
> David Goodenough wrote:
> > On Monday 30 March 2009, Mark Thornton wrote:
> >> David Goodenough wrote:
> >>> 5 years as near to indefinitely as matters).  I need compiler
> >>> checkability for field references now.
> >>
> >> Define an annotation
> >>
> >> @interface @fieldReference {
> >>     String name();
> >> }
> >>
> >> class MyClass {
> >>     @fieldReference("myField") static FieldRef FIELD_REF;
> >>
> >>     static {
> >>        // use reflection to set initialise static fields with
> >> @fieldReference annotations
> >>     }
> >> }
> >>
> >> You could use an annotation processor to verify that the @fieldReference
> >> named valid fields and was attached to a suitable reference field. There
> >> are probably other ways of doing this, but it does give you the compile
> >> time check you want without requiring a language change.
> >>
> >> Regards
> >> Mark Thornton
> >
> > My first instinct when I read this was that this was another example of
> > moving the problem to a better place (the place where the field
> > originates rather than the place where you use it) but that it was still
> > uncheckable.
>
> ...
>
> > The only niggle that strikes me immediately is that existing beans will
> > not be suitably annotated, and this includes all the Swing screen widgets
> > (subclassing or a helper class can solve that as it is a well defined
> > set) and classes built by schema scrapers from places like existing SQL
>
> You could add an optional field to the annotation which specifies the
> class defining the field. This would default to null, meaning the
> current class if not specified. Now you can declare them anywhere and
> don't need to modify existing classes. Someone with more experience with
> annotation processors than I have could probably come up with a much
> neater scheme.
>
> > I will have to try this and see if it solves the problem.  If it does
> > then I will happly withdraw my proposal, and stop getting in everyone's
> > hair.
>
> Although your proposal isn't large in itself, it intersects with many
> other proposals in the same area which are clearly large (and outside
> the scope of Coin). This makes it difficult to consider without also
> evaluating those other proposals.
Actually I have been thinking about this, and I do not believe that my
proposal would preclude those other bits of the full properties proposals
when (if) they eventually get considered for inclusion into Java. 

The full properties discussion breaks down into two bits.  The first, and this
seems actually to be where most of the problems lie, is stuff that Java can
do today.  it just does it in a way that is not as simple and easy to read and
write as it might be.  In my book that makes is desirable to fix (I am all
for ease of use) but not necessary to fix (its not a show stopper).  And one
can see in the list of Coin proposals that are being progressed several
fall into this same category.  For example the switch on string can be 
expressed as an if tree, its messy and the new proposal is much nicer, but
it is only desirable not necessary.

The problem that I was having all along was not the bits of the property
proposals that can be done already, it was the bit that I could not find a 
compiler checkable way to do today (but which you may have solved).
That (as a show stopper) I class as necessary and desirable.

I have spent too much time fixing code that got the string form of field
names wrong (both in my own code and in that of others) for comfort,
and in a language that generally catches such things up front and won't
compile wrong code this is a big problem.

Having the primitive hat gets me a FieldRef (I like that name) is exactly
what I need, and it can then be used under the covers in the implementation
of the full properties solutions later.  I see nothing that they need that my
proposal actually precludes or even makes it difficult.

Actually you do need a little more than a Field object.  Firstly it can be a 
Field array (if you have compound names - Foo#bar#ali or foo#bar#ali) and 
secondly having checked that bar and ali are valid in this context it does 
seem silly to loose the reference to the class Foo or the instance foo 
and then put them back again and have to check all over again when you 
come to use it the Field object.

In addition getting a FieldRef object is a simple matter of calling a 
constructor or factory method, so it is very easy to de-sugar in javac.
Getting a Field object is more complicated because it would either
require looping up the superclass chain (java.lang.Class.getDefinedField
only looks in the current class) or (and this would rule it out of Coin 
immediately) it requires a change to java.lang.Class to add a new 
method which does the climbing up the super class chain for you.

David
>
> Anyway I hope my suggestion allows you to get the compile time
> validation you want without waiting another month let alone a year or
> even 5 years.
>
> Mark Thornton