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

[rssh at gradsoft.com.ua]

> 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.
>

Generated persistent scheme class contains all information. Extend one
to define all properties as constants in generated class is easy.
Generation can be done with annotation processor.



> 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
>
>
>
>