On Tuesday, March 11, 2003, at 04:03 PM, Peter Romianowski wrote:
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: /.
BASIC!!! And the next step would be introducing type sigils... Sorry for the sarcasm, but I'm a discrete kind of guy. If any operator should be second-class, I'd say it be the *real* division, not the integer division. But to add some constructive criticism to the issue, "div" and "mod" are the Algol-ish names for the integer operators. I can live with that. MS BASIC used "\" for integer division; I can live with that, too.
And modulo is quite simple:
#macro(mod x y)
#set($res = $x - ($x / $y)*$y)
$res
#endI 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.
You *have* to populate the ArrayList in the first place, haven't you? ;-)
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...
This is precisely my point. I refuse to be taxed in the name of the needy :-)
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?
Now here lurks a problem (I felt like I was going down the primrose path, now I know I did): if you convert types, how do you know which method to call, out of a set of overloaded methods? I'd say, it depends:
#set( $value = $tool.someLong ) $someTool.doSomething($value)
should work.
#set( $value = 5 ) $someTool.doSomething($value)
should not. That's why I strongly advocate syntax-based typing of constants (and why C does it, C++ does it, Java does it, C# does it...): 5 is an integer, 5L is a long, 5.f is a float, 5. is a double. After all, true is a boolean and "hello" is a string and nobody complains.
However, I believe that BeanUtils does this conversion type of thing.
Mat�as.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
