Most examples i know involve classpath scanning at startup, so runtime performance isn't a concern. I suppose we could do likewise and scan the whole classpath at startup looking for @Template<Type> and @Render method annotations at startup. But again, that seems like overkill for the feature in question.
On Sat, Dec 25, 2010 at 10:00 AM, Will Glass-Husain <[email protected]> wrote: > 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
