nice discussion. proposal, civil airing of pros and cons, apparent decision by consensus. (yes on TemplateNumber, no on comparing Strings and numbers). appreciate it. Let's try and do more of this.
I'm in favor of extending <, <=, >, >= to include objects that implement Comparable. It'll make the operators work with Strings and Dates by default, which will be nice. WILL ----- Original Message ----- From: "Peter Romianowski" <[EMAIL PROTECTED]> To: "Velocity Developers List" <[EMAIL PROTECTED]> Sent: Thursday, June 26, 2003 12:32 PM Subject: Re: Velocity Numerics [PATCH] > Will Glass-Husain wrote: > > > Thanks Tim, > > > > Good point. Here's one that's even more puzzling. > > > >>#if ( "42" == "42.0" ) What should this do? #end > > > > > > if 42 == "42.0" and 42 == "42" but "42" != "42.00" that's pretty strange. > > In german notation 42 == "42.0" would fail (since the '.' is not the decimal > point). Others had this and more points why this would be A Bad Idea(tm). > > I suggest that we completely drop the idea of comparing Strings to Numbers. > It simply raises more problems than it brings benefits. I cannot imagine > the use cases (or at least not that much) for that since we have typed variables > in velocity and java. The approach with the TemplateNumber-interface is by far > the better choice in case of dealing with numbers and non-number-types. > > Personally I am not a friend of the Use A Tool(tm) strategie but this time > I think it fits best. Programmers should pay attention to what they throw > into the context and if a comparison is definetely needed then a tool > should be used. > > Another point that has been discussed is the usage of dates for example > whithin comparisons. The == operator already deals with objects since > it calls the .equals() method for non-numbers. I would like to widen > this up so that < > and == work with classes that implement the Comparable- > interface. This way you can compare Dates (since java.util.Date implements > the Comparable-interface) and any other object where the Programmer desided > whether it should be comparable or not. Implementation could be a bit tricky, > but I think it's worth it. Will and all: What do you think? > > Peter > > > WILL > > > > ----- Original Message ----- > > From: "Tim Colson" <[EMAIL PROTECTED]> > > To: "'Velocity Developers List'" <[EMAIL PROTECTED]> > > Sent: Thursday, June 26, 2003 11:47 AM > > Subject: RE: Velocity Numerics [PATCH] > > > > > > > >>>Will Glass-Husain said: > >>> > >>>>I'm not sure I see a downside to including this (ability to compare > >>>>numbers and Strings). > >> > >>-1 > >>Hmm... I'm fond of Perl, but string to number comparisons would, imho, > >>increase ambiguity in comparisons. Examples: > >> > >>#if ( 42 == "42" ) Perl says true but what does Velocity decide? #end > >>#if ( 42 == "42.0" ) Perl says true but what does Velocity decide? #end > >>#if ( 42 == "4.2e1" ) Perl says true but what does Velocity decide? #end > >>#if ( 0 == "0" ) Perl says true but what does Velocity decide? #end > >>#if ( 0 == "foo" ) Perl says true but what does Velocity decide? #end > >> > >>I support that numbers including float should Just Work (tm) and want to > >>be able to type #set ( $foo = 5 / 2.5) but fear the negative effect of > >>weird/ambiguious comparison rules between numbers and strings. > >> > >>-Timo > >> > >> > >> > >> > >>--------------------------------------------------------------------- > >>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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
