How would that prevent people from writing nonsensical declarations? It seems confusing to have one annotation with a bunch of attributes, one for each type. It feels likesome hackto me. Having specific annotations seems foolproof.
Gary <div>-------- Original message --------</div><div>From: Matt Sicker <boa...@gmail.com> </div><div>Date:05/26/2014 15:19 (GMT-05:00) </div><div>To: Log4J Developers List <log4j-dev@logging.apache.org> </div><div>Subject: Re: PluginAttribute vs. IntPluginAttribute </div><div> </div>We can choose which attribute of the annotation to use based on the type the annotation is attached to. That wouldn't be too hard. On 26 May 2014 08:34, Gary Gregory <garydgreg...@gmail.com> wrote: On Mon, May 26, 2014 at 9:02 AM, Remko Popma <remko.po...@gmail.com> wrote: On Mon, May 26, 2014 at 9:58 PM, Gary Gregory <garydgreg...@gmail.com> wrote: A recent commit contains: + @PluginAttribute(value = "blocking", defaultValue = "true") final boolean blocking, Using a String default for a non-string attribute seems like a punch in the eye ;-) This really feels unnatural. Currently, I cannot say: @PluginAttribute(value = "blocking", defaultValue = true) final boolean blocking, @PluginAttribute(value = "someInt", defaultValue = 123) final int blocking, That would require the annotation attribute's defaultValue to be typed as an Object which is illegal. Would it be an idea to have different attributes for the default value, one for each type? @PluginAttribute(value = "blocking", defaultBooleanValue = true) final boolean blocking, @PluginAttribute(value = "someInt", defaultIntValue = 123) final int blocking, I do not think so. What would this mean: @PluginAttribute(value = "foo", defaultIntValue = 123, defaultBooleanValue = true) final int blocking, ? Gary I suggest: @BooleanPluginAttribute(value = "someBool", defaultValue = true) final boolean blocking @IntPluginAttribute(value = "someInt", defaultValue = 123) final int blocking If not, then at least say: @PluginAttribute(value = "blocking", defaultValue = TRUE) and do a static import of TRUE from our Strings class (assuming you'd add TRUE to Strings). If we are going to do typed configuration with a custom annotation mechanism it seems inevitable to have to go with IntPluginAttribute, and so on. Using mixed types looks very odd. Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- Matt Sicker <boa...@gmail.com>
