velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <ge...@optonline.net>
Subject Re: comparing monetary value
Date Fri, 18 Oct 2002 08:03:21 GMT
On 10/17/02 10:57 AM, "Peter Romianowski" <megapero@gmx.de> wrote:

> Just to end this thread, could one of the developers answer this
> (very constructive) mail (I mean the one from Daniel) in *detail*.
> I would love to use decimals too and I don't see why people deny that,
> BUT nevertheless I love Velocity and I would *really*, I mean like
> *desperately really* :), know why there are no decimals but only
> integers supported. The number-formatting-feature is not the point,
> that should be done by a tool.

I've said before that I think that support for floating point in comparisons
is something we should consider, and will be happy to put the code in once
we decide which way to go, if we decide that way.  It's not that hard.

I'm happy to have a constructive conversation about this stuff and while
time is really tight, I'm happy to work on changes we want....

> 
> Simply put, why is #if ($myIQ < 42.5) BAD? I know the answers are in
> this and that mail, but please give me a simple single sentence starting
> with "Velocity does not support decimals, because ...". I already
> realized (partly the hard way :) that you will not implement decimals.

I think of this as two separate things.

First there's the "<", which I have mostly changed my mind about - being
able to do  :

  if ($price < $maxPrice)

is a natural thing although it is the thin end of the wedge :)  A purist
will argue that you want something else in the model to indicate this for
you.  I like to think about the purist approach (with anything) but as I'm a
realist doing real things, life doesn't always work out so you can do that.

The second is the literal "42.5".  This is the aspect that bugs me a bit
more, as [putting on purist hat] it's putting what is *probably* model data
into the template.  Of course, I say probably as there is  plenty of room to
legitimately disagree on what is model on an app by app basis...


> I will not switch over to another template engine, because Velocity's
> simple design *rocks* (note: no contradiction here), although some
> development could be done (decimals, macros, perhaps
> whitespace-gobbling).
> 
> I would like to end this thread in a *nice* way, not saying "hey
> man, go use something else" or "hey man, you suck" from each of the
> "parties" (not that someone said something as rude as that).
> 
> My $0 (<- result if ${2/100} - sorry for that :)
> 
> Peter
> 
> 
>> -----Original Message-----
>> From: Daniel Dekany [mailto:ddekany@freemail.hu]
>> Sent: Thursday, October 17, 2002 5:23 AM
>> To: Velocity Users List
>> Subject: Re: comparing monetary value
>> 
>> 
>> Thursday, October 17, 2002, 2:22:14 AM, Geir Magnusson Jr. wrote:
>> 
>>> On 10/16/02 3:19 PM, "Tim Colson" <tcolson@cisco.com> wrote:
>>>> Note: seems fair to disclose that Jonathan, to paraphrase the
>>>> FreeMarker website, "rewrote the core of FreeMarker".
>> Also, I noticed 
>>>> that Daniel is heavily active on the FM-DEV list. It
>> puzzles me, but 
>>>> I will not speculate on why these gents are so worked up
>> about having 
>>>> this feature in Velocity, since by Jonathan's own explanation, it
>>>> already exists in the Freemarker template engine which both chaps
>>>> seem to prefer.
>>>> 
>>> 
>>> Yes, I too wonder why Jonathan and Daniel are so worked up
>> about this.
>> 
>> <OT>
>> Could you please stop this "Jonathan and Daniel" thing... It
>> such a waffle. If someone wonder, I tell you why I'm here:
>> Simply, I heard that Jonathan is here, and I was Velocity
>> list reader in the pre-FM 2.x times, and I was curious what
>> will happen now. And I just can't stop myself to reply when I
>> see something nonsense. It has nothing to do with the fact
>> that I'm involved in FM. What's then? I don't get payment for
>> FM users... </OT>
>> 
>> So... returning to the essence...
>> 
>> I don't understand why are you so reluctant about decimals.
>> (Well, frankly, I have an idea, but I don't tell it again.)
>> What are your counter arguments? (I ask you because you are
>> the leader developer here, AFAIK.)
>> 
>> To prevent needles communication, here are a few
>> counter-arguments, and why are they invalid (IMO). I don't
>> say here that you say these counter-arguments.
>> 
>> 1.
>> - Decimals inherently problematic because of the rounding
>> complications (1.49999999999999 and such things).
>> - Yes, but decimals are existing in the real-life. Is this a
>> good logic when someone does not solve something because the
>> solution is not trivial? Obviously it does not make sense.
>> Also, exactly because it is not a trivial topic, it is better
>> if Velocity solves this, than leave individuals to develop
>> tools for it.
>> 
>> 2.
>> - It would complicate/distort the syntax.
>> - I don't think so. The only point where it touches the
>> syntax is that you can write constants like 1.5. But it is
>> just a little extension of the syntax, right? Also, it is
>> such an obvious thing.
>> 
>> 3.
>> - It would complicate/distort the semantic.
>> - From the viewpoint of designer it would *simplify* the
>> semantic. Everyday people find it natural that he can use
>> decimals. Integers and decimals are not separated so strictly
>> in the brain of non-programmer. They are just all numbers.
>> What they don't find natural is that 90/100=0 (since it is
>> nonsense), or that they can't compare two numbers, because
>> one of them is not integer.
>> 
>> 4.
>> - Velocity should solve number formatting then.
>> - It is cleanly an MVC view task, right? So it is the task of
>> Velocity. Anyway, you must solve it, wether you like it or
>> not, and now you are forced to solve it with custom tools.
>> Not to mention that number formatting issues are existing
>> even if you support integers only (e.g. someone may use
>> grouping when display integers.) A standard tool is a
>> possible solution.
>> 
>> 5.
>> - We just discuss that we will develop a standard tool...
>> - That's OK for solving the formatting problem, but in fact
>> it has nothing to do with the question (i.e. supporting
>> decimals or not). Operators still will not work (90/100 = 0,
>> relational operators don't work...). I know, you can use
>> tools for do these things, but this in itself is not a
>> counter-argument... maybe you can say that it makes decimals
>> +0 in this field. However, I would disagree then: would not
>> it be much better if 1/2 is simply 0.5?
>> 
>> 6.
>> - Designers needs only integers
>> - I don't think so, but that's a somewhat subjective
>> question. Also, I guess the number of requests means that it
>> is not that uncommon thing that someone need decimals. But
>> even if they need it 1 times per 1000 year (I doubt), in
>> itself it is again a +0 argument.
>> 
>> 
>> So the main point is that simply I don't see a reason
>> *against* decimals (while I and many other uses see reasons
>> *for* decimals). Why would be that harmful?
>> 
>> So, what are your *counter-arguments* against decimals?
>> 
>> 
>> --
>> To unsubscribe, e-mail:
>> <mailto:velocity-user-> unsubscribe@jakarta.apache.org>
>> For 
>> additional commands,
>> e-mail: <mailto:velocity-user-help@jakarta.apache.org>
>> 
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:velocity-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:velocity-user-help@jakarta.apache.org>
> 

-- 
Geir Magnusson Jr. 
geirm@adeptra.com                                    +1-203-355-2219 (w)
Adeptra Inc.                                         +1-203-247-1713 (m)



--
To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>


Mime
View raw message