On Tuesday, March 11, 2003, at 02:12 PM, Peter Romianowski wrote:
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
If $product.amount is a real number, this would be desirable. However, if this means that / always produces a fraction, I don't like it. Intuitive or not, integer division is an important operation that can't go away. For example, try to format an almost-rectangular array (in a calendar, by way of concrete example) without entire division and modulus.
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...
I fully agree with you that simple tallies can be done in VTL, and that is reasonable. It breaks the VTL philosophy, however, of not doing business logic in the template, so this can come under attack on that basis. You can as easily add an average attribute to the context.
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.
Introspection and marshaling should be type-transparent, in that I agree.
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.
Maybe I misunderstand you, but how so? If you mean widening to long, operating and getting a long result, then yes, you have to narrow down to int; but if you fix the marshaling to narrow/widen to the type of the parameters, you get that automatically.
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
Now I see what you mean. It's what ANSI C does: it widens to the widest type in the expression type, and then narrows back to the type of the result, so that, for instance:
int res = 5L * (2f - 3);
widens the "3" to a float, does a float subtraction, widens the result to a long, multiplies by 5 and then narrows down to an int. K&R C did differently, in that it widened everything to int and/or double first, and then to the size of the largest argument if needed. The advantages of "widen to narrowest comprising" (ANSI C) is that you don't lose control of the sizes in every step of the evaluation. In the situation of VTL where you don't have a means to declare the type of the operands, there is not much difference, and "widen to widest comprising" opens up the door for optimizations (i.e., elimination of widening steps) based on analysis of the expression tree.
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)
I don't like this. Again, it feels like a tax on "ease of use". 2^N - 1 + 2^N - 1 == -2, modulo 2^N. That is mathematically correct and understandable.
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)?
I'm sorry for being obscure. What I meant was that I see fixing expressions and method calls and results as two different things that might be tackled separately. I agree that this (given the right Tools) should work:
#set( $cal = $dateTool.calendar($system.currentTimeMillis()) )
I am prepared to wait on this:
#set( $totalPrice = $unitPrice * (1.0 + $tax / 100.0) )
Mat�as.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
