> On Tuesday, March 11, 2003, at 08:51 AM, Peter Romianowski wrote:
>
> >> I don't think FP would break existing templates if implemented with
> >
> > Unfortunately it does. #set ($foo = 5 / 2) will result in
> $foo being
> > 2.5 instead of 2.
>
> As I pointed out before, it need not be. The only contentious point
> remaining is the "confusing" syntactic difference between an integer
> (without a decimal separator) and a real (with an obligatory decimal
> separator); beyond that, automatic widening/coercion is
> transparent and
> well understood.
>
> One possible compromise would be explicit coercion, possibly via a
> tool. For instance,
>
> #set ($foo = 5 / 2)
>
> would set $foo to 2 as before, but
>
> #set ($foo = $types.asDouble(5) / 2)
>
> (or any variation thereof) would set $foo to 2.5.
>
> Another possibility to consider would be to have one unified
> syntax for
> numeric constants (with or without decimal separator), but
> two sets of
> operators, � la Caml: + - * / for integer operations; +. -. *. /. for
> real operations. I'm just mentioning so as to bring it up for
> consideration, not that I'm advocating it.
I try to view at all this from the designer POV. Velocity's syntax is so
simple and designers are quite closer to Javascript and stuff (if even)
than to "real" programming languages with all their distinction in types.
Having different #set or operator-syntax would make VTL more complicated.
I fully understand your concerns on that. From my POV the current velocity
behavior is the "broken" one and full number support is the "correct" behavior.
I know that some people have different thoughts on that. So from my POV it
is no problem breaking backwards compatibility since I believe it will
/ must be broken in some other ways too (whitespace handling, escaping).
> >> I'd say that any application sensitive enough to overflow to care
> >> should implement careful (pardon the redundancy) business logic
> >> outside
> >
> > That's for sure! But I really don't see why something like
> displaying
> > a progress bar ("10.23 % finished") would require any
> business logic.
> > Other things like displaying a total price should go into
> the business
> > logic or controller, since there might be rounding issues. For my
> > everyday use I find enough cases where I simply need numbers or the
> > possibilities
> > to compare floats.
>
> These are really two separate issues. "10.23 %" is a formatted
> representation of a number (which might be more accurately written as
I just meant something like:
#foreach ($product in $list)
...
#set ($totalAmount = $totalAmount+$product.amout)
#end
#set ($avg = $totalAmount / $product.size())
The average amout of items per product is: $avg
Ok, this could be done in the controller some might say. But I don't like
to iterate multiple times, if not nescessary. You could use a tool, but
it would not be as elegant. "Use a tool"(tm) when there is a lack in the
syntax (my POV) is not desirable. You cannot understand the VTL by just
reading it, since simple things are done within a tool...
> 0.102299995). On the other hand, comparison of floats and
> such I think
> would be desirable. In general, independently of input (#set) and
> output (dereferencing), the operators should transparently understand
> all native types as they might be the results of a method invocation.
Yes.
> I know that "anecdote" is not the singular of "data", but in my
> experience we never had a problem with this, although we're using
> Velocity to enter to and display information from a rich
> database-based
> application.
As said, I had a lot of trouble since nearly all of my business-objects
are using a long as their id. And that made it quite complicated, since
I cannot use a long as a method parameter. Or comparing floats. Most times
I just have to check whether something is 0. And that does not work with
long, byte, short, float and double.
> I don't mind the overhead of having the built-in numeric
> types handled
> in a dynamic, scientific-calculator-like way (where a number is a
> number even if the representation changes). If implemented well, that
> could be very flexible and intuitive.
>
> I'd like to point out that it's more usual to widen before operating
> instead of dispatching on the type, thus:
>
> Number widen(Number n) {
> if (n instanceof Long || n instanceof Double)
> return n;
> else if (n instanceof Byte || n instanceof Short || n
> instanceof
> Integer)
> return new Long(n.longValue());
> else if (n instanceof Float)
> return new Double(n.doubleValue());
> else
> throw new IllegalArgumentException("widen");
> }
>
> Number add(Number l, Number r) {
> l = widen(l);
> r = widen(r);
> Number res;
> if (l instanceof Long && r instanceof Long)
> res = new Long(l.longValue() + r.longValue());
> else
> res = new Double(l.doubleValue() + r.doubleValue());
> return res;
> }
Works quite the same way the proposed patch works. Besides: The patch
converts the result back to the smallest type it fits into. The
final version should not do that much type conversion since you
can get a lot of trouble if you add two ints and use the result
to call a method which expects an int. So I think the arguments
should be widened and then the resulting type should be determined
on the basis of this matrix:
Integer + Integer = Integer
Integer + Byte = Integer
Integer * Float = Float
...
Handling of overflows is a different thing. There are basicly
two alternatives:
1. don't handle overflows
Integer.MAX_VALUE+Integer.MAX_VALUE will be -2 IIRC ;)
or 2. handle overflows
Integer.MAX_VALUE + Integer.Max_VALUE = (Long)Integer.MAX_VALUE*2
The current patch implements version #2. But for the reasons
written above (expecting certain types) I currently don't know
which one fits best. (But tending to #1)
> This implements my suggestion that 5/2 == 2 but 5.0/2.0 ==
> 2.5; if not,
> widen everything to double and eliminate the first branch of the
> conditional in add().
>
> If the Velocity compiler can do some kind of static analysis on the
> expression tree, then a number of widening operations can be
> optimized
> out.
>
> >
> >
> >> If I'm allowed to vote, I'd
> >>
> >> -1
> >>
> >> on the numeric proposal as it is now.
> >
> > With the things I said now, what would be your vote? +0? Yours and
> > mine vote wouldn't count, but I'd like to know.
>
> +0 on the basis of perceived (by me) necessity; +1 on the basis of
> orthogonality. I'm very mixed on this because, on one hand I think
> elegance overrides usefulness, but on the other I'd err on
> the cautious
> side on this issue. I'd rather cast a +0.5 (no pun intended)
> and break
> a tie.
>
> Would separating the numerics proposal in two, i.e. enriching the
> numeric tower vis-�-vis the unified, consistent handling of numeric
> results make it more acceptable to the community?
Sorry, what do you exactly mean (maybe my english is too bad)?
Peter
> Mat�as.
>
> ---------------------------------------------------------------------
> 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]
