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]
