On Wednesday, March 12, 2003, at 02:12 PM, Peter Romianowski wrote:
On Tuesday, March 11, 2003, at 06:51 AM, Peter Romianowski wrote:
$foo beingI don't think FP would break existing templates if implemented with
Unfortunately it does. #set ($foo = 5 / 2) will result in2.5 instead of 2.
Well.... Try this :
System.out.println(5/2);
It prints 2.5 ... No, just kidding :)
LOL. You should of let me go check again :)
The proposed patch would make
5 / 2 = 2.5 and that'd be the desired behavior (getting away from
Java-Number-Types)
Within Velocity I'd like to be able to use just *numbers* and I don't
want to hazzle around with Integer vs Long vs Float vs ... But I know
that this topic is really complicated since there is no "100% right" way.
And when all the introspection things comes in it get's even more complicated.
The basic question is: Is Velocity supposed to be a *Java*-Template
Language? If so, then things like casts *must* be implemented. If you
have all the type-stuff (Integer, Long, Double) available and you have
to handle it, you should be able to cast IMO... Until now Velocity does
a lot of things to overcome Java-Strictness, like accessing beans and
maps the same way. I mean if we distinguish between Integer, Long, Float
and so on, why don't we distinguish between Maps and Beans too?
I think that VTL should *not* be Java-centric where we can avoid it. Designers don't know Java, and when you need specifics, you can always toss in a tool. (Take that argument further and.... ;)
Aside : I had always hoped, for example, that Cheetah (Python templating system) would work towards VTL support. They didn't - that's fine - and they did things in the template language that is dripping with Python. This hasn't held them back....
[SNIP] I keep going round and round in my head about this. I keep wondering if there is a clean way to introduce this w/o breaking templates.
The easiest way would be to introduce new operators. But that might be ugly. The only operator that raises real trouble is / AFAICS If the /-operator thing is solved then there should only be problems with code now working that hasn't worked before, like this:
($myLong is a Long) #set ($myValue = 5) #if ($myValue < $myLong) .. #end
This code would raise a warning now but will work with number-support
included. I tend to think that these cases can be negelected. Another issue
is the overflow-handling. If we decide to implement it (if we get a way from
all the type-thing, then it *must* be implemented IMO) then perhaps
seldomly cases like:
($myValue = Integer.MAX_VALUE) #set ($myValue = $myValue * 2)
In the current version this results in $myValue being -2 IIRC. In the new
version $myValue would be Integer.MAX_VALUE*2 and a Long.
Yes - that would be pleasant. Baffling for someone who has a clue, but we could always badger the tools crew to have a 'JavaMath' package :)
geir
Regards,
Peter
geir
-- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m)
--------------------------------------------------------------------- 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]
-- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-434-2093(m) [EMAIL PROTECTED] 203-247-1713(m)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
