The main advantage is convention. Java development has clearly shifted towards annotations as a way to handle exactly this type of issue.
Having said that, either approach seems reasonable to me. WILL On Sat, Dec 25, 2010 at 11:22 AM, Nathan Bubna <[email protected]> wrote: > Yeah, they're nice, but i'm actually having second thoughts about > offering them due to performance/complexity concerns. Scanning the > class heirarchy of each reference value for an invokable method with > the right annotation (and, hopefully, signature) seems like a bad > idea. Even if the results are cached by Class, it seems like a lot of > work just to give users flexibility about which method they want to > use. I think we'd need to have a convincing reason that annotations > are clearly superior to the getAs<Type> convention, which also plays > nicer with keeping the interfaces available. > > On Sat, Dec 25, 2010 at 7:16 AM, Will Glass-Husain > <[email protected]> wrote: > > I like the annotations idea a lot. > > > > Annotations are pretty mainstream by now, and also very convenient. > > > > Will > > > > P.S. Happy Christmas! > > > > On Friday, December 24, 2010, Nathan Bubna <[email protected]> wrote: > >> Ok, we've taken some good steps toward this in the past (via > >> Renderable, TemplateNumber, get, put, and good ol' toString(). With > >> 2.0, it's long been a major goal of mine to step it up a bit. There > >> are options. I have my opinions, but thought it best to consult ya'll > >> before i started in on it. > >> > >> 1) add missing interfaces: TemplateString, TemplateBoolean > >> 2) annotations: @TemplateNumber, @TemplateString, @TemplateBoolean, > >> @TemplateRender > >> 3) convention: getAsString(), getAsNumber(), getAsBoolean(), > >> render(context, writer) > >> > >> #1 is great for people who want compile-time checking, but makes > >> velocity a runtime dep for users. i am not content to leave it at > >> that, but i am willing to keep and complete the interfaces if people > >> still find them useful. > >> > >> #2 lets people name methods whatever they want, but makes velocity a > >> compile-time dep for users. > >> > >> #3 no dependency, but no compile time guards. this is also more the > >> way we've been doing things. > >> > >> i am willing to do #1 with either #2 or #3, but not all three > >> together. i'm also perfectly happy to drop the TemplateNumber > >> interface and discourage external use of Renderable, if people see > >> little use in them. performance is a concern for the string/render > >> stuff, as the check will happen for every non-String value that > >> results from a $reference evaluation. and the boolean check will > >> happen for every #if( $ref ). number checks will of course happen > >> anytime math is involved. > >> > >> also, we might later want to discuss if we want to apply these > >> checks/conversions to $method.expectsBoolean($hasGetAsBoolean). i > >> think we should, but we haven't done that in the past, so it's not my > >> first priority. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
