You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Nathan Bubna <nb...@gmail.com> on 2010/12/24 22:18:18 UTC
duck typing
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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: duck typing
Posted by Sergiu Dumitriu <se...@xwiki.com>.
On 12/24/2010 10:18 PM, Nathan Bubna 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.
Personally, I prefer not to require a strong dependency on Velocity. So
my favorite is 3). 3) can go very well along with 1), if these methods
will be part of the interfaces.
> 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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: duck typing
Posted by Nathan Bubna <nb...@gmail.com>.
That saves some processing but adds complexity for users and us. I
think the fundamental difference here between this and most annotation
setups is that this is just about rendering objects and is meant to be
a completely optional feature of a component library for the view
layer. It is far more common to use method annotations for controller
location/config in frameworks. So while both involve identify the
method meant to be used for a function, the reality is that this
feature just isn't worth the level of effort/complexity inherent in
using annotations for it.
Given the way that #3 (for those who dislike dependencies) can work
seamlessly with #1 (which offers the best compile time checks for
those who like them), that's the way i'm going to implement it.
On Sat, Dec 25, 2010 at 6:06 PM, Will Glass-Husain
<wg...@gmail.com> wrote:
> We could work like Spring and specify a list of packages to scan in
> the configuration set up...
>
> Will
>
> On Saturday, December 25, 2010, Nathan Bubna <nb...@gmail.com> wrote:
>> 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
>> <wg...@gmail.com> 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 <nb...@gmail.com> 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
>>>> <wg...@gmail.com> 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 <nb...@gmail.com> 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: dev-unsubscribe@velocity.apache.org
>>>> >> For additional commands, e-mail: dev-help@velocity.apache.org
>>>> >>
>>>> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: duck typing
Posted by Will Glass-Husain <wg...@gmail.com>.
We could work like Spring and specify a list of packages to scan in
the configuration set up...
Will
On Saturday, December 25, 2010, Nathan Bubna <nb...@gmail.com> wrote:
> 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
> <wg...@gmail.com> 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 <nb...@gmail.com> 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
>>> <wg...@gmail.com> 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 <nb...@gmail.com> 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: dev-unsubscribe@velocity.apache.org
>>> >> For additional commands, e-mail: dev-help@velocity.apache.org
>>> >>
>>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: duck typing
Posted by Nathan Bubna <nb...@gmail.com>.
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
<wg...@gmail.com> 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 <nb...@gmail.com> 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
>> <wg...@gmail.com> 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 <nb...@gmail.com> 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: dev-unsubscribe@velocity.apache.org
>> >> For additional commands, e-mail: dev-help@velocity.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>> > For additional commands, e-mail: dev-help@velocity.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: duck typing
Posted by Will Glass-Husain <wg...@gmail.com>.
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 <nb...@gmail.com> 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
> <wg...@gmail.com> 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 <nb...@gmail.com> 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: dev-unsubscribe@velocity.apache.org
> >> For additional commands, e-mail: dev-help@velocity.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: dev-help@velocity.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
Re: duck typing
Posted by Nathan Bubna <nb...@gmail.com>.
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
<wg...@gmail.com> 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 <nb...@gmail.com> 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: dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: duck typing
Posted by Will Glass-Husain <wg...@gmail.com>.
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 <nb...@gmail.com> 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: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org