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]
