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]
