Will Glass-Husain said: > I'm not sure I see a downside to including this (ability to compare numbers > and Strings).
one downside to me is demand for this particular. i haven't seen too much of it. and if there's little demand, the likelihood of good support for the feature decreases too. i think velocity could use some new features too, but let's keep modest goals that match demand and not get all feature-happy with individual pet features. float support should be in and working before we even consider such a feature as this. > Template designers are not programmers. When they hit > problems (particularly those involving types), it'd be nice if most things > just worked. if we are dealing with "mere designers," then we are working with those who do not control what is put into the context. if the developer is putting things into the context that ought/need to be compared with numbers or operated on as numbers, then it should be their responsibility to implement TemplateNumber (yes, i like the idea of that interface). basically, references already in the context for the designer should be used as developers intend. if they aren't, then i see that as a problem we should not be providing work-arounds like this for. as for designers creating a string literal in the template themselves and then wanting to operate on it as a number, i can't see how that is either necessary or a good idea. in other words, does anyone have a legit use case for this? > I can see a few counter points. It won't work well for formatted numbers > (and only for internationalized numbers in the current locale). And it's > not a common use case (as a few have pointed out) to compare 4.0 > "4.0". > If we include my TemplateNumber proposal, then the developer can always wrap > a String with an adapter that implements TemplateNumber so that it is > properly comparable. Thus, (personally), I don't need this feature that > badly. yeah, i'm really not sure who would need it. i agree with Jonathan; this is a Bad Idea (tm). it is taking a half-hearted and unnecessary step toward utter-typelessness. i don't think that's where this project should go, especially with its heavy use of reflection. once we let designers do just about anything with VTL operators, then they'll just be confused why $mytool.this_method_takes_an_int( "4.13" ) doesn't work. types are here to stay and we need to be very careful when we blur the lines I think designers are perfectly competent to deal with a few simple types--numbers, strings, and objects. if they really need to do a string to number conversion, there will always be Use A Tool (tm). the velocity-tools' MathTool will do this quite happily. > But as I say above, I don't see a big downside to including it. Some might > say... If you don't want it, don't use it. yeah, but who supports it (bug fixes, user list questions, etc)? one more thing is one more thing and additional complexity without substantial demand for it is a bad idea IMHO (especially this particular addition). Nathan Bubna [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
