[typesafe properties access](was Re: For further consideration...

David Goodenough david.goodenough at linkchoose.co.uk
Tue Mar 31 02:19:56 PDT 2009


On Tuesday 31 March 2009, rssh at gradsoft.com.ua wrote:
>  Just note, that similar problem was quite elegant resolved in JPA-2.0 API
> http://in.relation.to/Bloggers/ATypesafeCriteriaQueryAPIForJPA
But that proposal still requires the use of uncheckable field names as
strings.  The second code block contains all those strings, and the comment
above it says exactly that you have to use string based names.

David
>
> > 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.
> >
> > But then you suggest using the annotation processor to do the
> > verification process, and that does seem to answer the question.  Its odd
> > that none of the potential users of this (Binding frameworks, Criteria
> > like APIs, and
> > PropertyChangeSupport) have used this approach which makes me a
> > little suspicious.
> >
> > 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
> > databases, or from XML schemas.  These would have to have these added
> > manually, or the tools that do the extraction would have to be modified.
> > But that is not a show stopper, its just a little extra work to be done.
> >
> > 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.
> >
> > David





More information about the coin-dev mailing list