> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
>
> Jon Stevens <[EMAIL PROTECTED]> writes:
>
> And I completely agree with Geir, that simply checking "is this a
> number and the blindly calling intValue()" is not a good solution. But
> having to use
>
> #if ( $data.Aktuell.intValue() > 0 )
>
> because
>
> #if ( $data.Aktuell > 0 )
>
> produces an obscure error is bound to drive people to php.
>
> Quote one designer: "But it is a number. It returns 0 to 2. So why
> can't I just use $data.Aktuell > 0 ?" Answering "because it is not an
> Integer but a Byte" produces a blank look in the best case.
>
> The solution with intValue() solved my problem with the template in
> the Template engine. Not in the Peer object creation or the underlying
> web application, but at the point where I recognized the problem. And
> I'm not really sure about Geirs' example because in the case of
>
> #if ($data.Float > 2.0)
>
> this IMHO would still work because the check whether both objects
> are of the same type would catch this.
>
> I, personally, would prefer to document the behaviour that "if the
> left and the right side of an #if() statement are not of the same Java
> object type, it is checked whether they're numerical types, and if
> yes, the comparisation is done with Integer values of these. If
> they're not of the same type and not both numerical types, a runtime
> error is reported". Because it would give us a documented behaviour
> that IMHO does not confuse the non-techie-guys.
>
> And it is (basically) the same thing, that other languages like perl
> and php do and that is the IMHO the user base that is moving over to
> solutions like Velocity.
>
Maybe the real issue here is that we need some more intelligent casting
rules. Like we have in those others interpreted languages. I do not think
just assuming Integer is the right choice. Assume you are comparing a Float
and a Double, for example.
One would need to have a real casting matrix for Numeric types:
Byte Short Integer Long Float Double
Byte - Short Integer Long Float Double
Short Short - Integer Long Float Double
Integer Intefer Integer - Long Float Double
Long Long Long Long - Float Double
Float Float Float Float Float - Double
Double Double Double Double Double Double -
Or something like that. The casting rules should apply not only to
comparisons but also to parameter passing, that would solve the particular
case here in a much more general way.
Of course, there is all the issues about ambiguous signatures, but hey they
are plenty of languages that have defined rules to dealt with this and we
could just borrow from there.
Jose Alberto
> Regards
> Henning
>
>
>
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen --
> Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
> D-91054 Buckenhof Fax.: 09131 / 50654-20
>