James Strachan | 2 Feb 11:31 2005

Re: using annotations instead of a keyword for bean properties

Agreed with all of that - and I like the use of flags on the  <at> Property annotation to enable veto or disable
bound property logic etc.

For namespace collisions, folks can always explicitly import annotations or modules with annotations
(something for the 2.0 pile)


On Wednesday, February 02, 2005, at 09:55AM, Jeremy Rayner
<jeremy.rayner@...> wrote:
>> So rather than a specific keyword; I'm thinking it'd be cleaner to use
>> annotations to annotate a field declaration which can act as a way to
>> make the getter/setter stuff, so that it is extensible or at least can
>> be in 2.0 of Groovy - later on we could allow folks to define their own
>> macros - but for 1.0 we define just one hard coded default
>> annotation...
>> class Person
>>     <at> property String name
>>     <at> property int age
>> }
>> further down the line we could consider adding  <at> unboundProperty or
>>  <at> vetoableProperty.
>> Thoughts?
>According to this good article by Brett
>the annotations can have value, so perhaps for minor variants you could have
> <at> Property(veto=true) String name
> <at> Property(unbound=true) int age
>> One comment, in Java 5 annotations are typed, so the convention appears
>> to be to use upper case names for annotations. So it might be better to
>> use
>> class Person
>>     <at> Property String name
>>     <at> Property int age
>> }
>> then it matches the feel of Java 5 annotations?
>Would we have a namespace clash, if somebody has defined a custom
>annotation of the same name as an inbuilt groovy one?
>lowercase  <at> property would save you most clashes
>uppercase  <at> Property would seem the most natural to Java5 folks
>I'd go with uppercase  <at> Property, and have some form of namespace
>collision device later