> 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
> #end
>
Yes, but after all I am sure that Velocity is supposed to be a *template engine*
and not a programming language. I'd totally agree on all the things you
say if we were discussing "How to do math the most correct way" ("correct" doesn't mean
that I don't care whether 2+3=5 of course! :). I'd like the idea of having a template
engine that concentrates on design and does allow some basic operations (and full
number support is basic for me). On this point I'd like to see more in the direction
of JavaScript and things. And that's why I don't like JSP that much. Having to deal
with imports, Class-Casting, Exception-Handling and so on is really annoying if you
want to concentrate on the design.
> >> 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.
>
> You *have* to populate the ArrayList in the first place, haven't you?
> ;-)
Not nescessarly. I often get Lists from methods on other objects. Or
compute them elsewhere.
> >> 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 :-)
But Velocity is a template engine, AFAIK :) I think both of us are really
having a different POV. That's good, of course. So I'd like to try to
find a solution that makes all happy or at least noone *that* disappointed :)
> >> 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,
That was my question.
> it depends:
>
> #set( $value = $tool.someLong )
> $someTool.doSomething($value)
>
> should work.
>
> #set( $value = 5 )
> $someTool.doSomething($value)
It depends on how the #set is implemented. If $value is a integer then
it should work. As said, the whole introspection is another issue. I
haven't spent enough time thinking about this.
> 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.
>From the template POV not nescessarly. For a template language I really
like the idea of untyped variables. This is not completely possible with
Velocity since it heavily depends on Java with Tools and Beans and Stuff.
(Don't get me wrong, having the ability to use Tools and Beans is a *great*
advantage!) So we cannot have untyped variables.
I'd like to make the whole number-issue quite transparent for the *template
designer*, but if it is a thing with heavy implications for many of the
community I could live with strict typing.
> After all, true is a boolean and "hello" is a string and nobody
> complains.
The other way around (as in JavaScript): "hello" is a variable and true
is a variable and nobody complains either :)
Peter
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
