> 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.
Wouldn't it be better to introduce a div and modulo operation? Modulo is
missing anyway IIRC! Finding a notation for modulo is simple: % What to
do with the div - the only thing that comes into my mind is the one that
you proposed: /.
> > 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.
Not without iterating through the list in the controller. And that is
double work. Performance-issues aside it is still some kind of PITA.
> >
> > 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.
Yes.
> > 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.
Again, I try to view at it a bit more from the template designers POV.
I am quite unsure when it comes to overflow handling, though...
> >> 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) )
Agreed. The first one is more of a bugfix, since it should work anyway.
Another question would be how introspection will be handled. Say I have
an Integer ($value = 5) in the context and a Tool or Bean with the following
method:
public int doSomething (long param) {...}
Will the VTL $myTool.doSomething($value) call the method? Since the
types of context-variables might change during the rendering process I
would say that it is required for primitives. Any thoughts on that?
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]
