Bools reloaded

[Ivan Senji]

xs0 wrote:
> Well, I believe that is just a matter of education/documentation. As 
> much as you need to know that && will short-circuit, you also need to 
> know that it will evaluate the operands as booleans. And, while 3 or 5 
> are definitely neither true nor false in themselves, one can certainly 
> define a conversion between them and booleans..

Sure, only question: does it makes sense to do that? Judging by the 
mayority of opinions it does make sense.

> 
> It's somewhat like Java's evaluation of "abc"+123. It's implied that 123 
> will be converted to a string form, and no-one seems to mind, even 
> though there is no implicit relationship between numbers and strings 
> (no, there isn't; 123 as a string could just as easily be "321"(*) or 
> "123.0000000000000", "onetwothree" or "WARNING: auto-conversion of 123 
> of type int to java.lang.String").. Would you also prefer
> 
> "abc"+String.valueOf(123)

it could be like in C#(if I remember correctly): "abc" + 123.ToString();
Well i certainly don't miss this aspect of Java in D. There is a good 
way (maybe a little longer) to do that in D.

> 
> or even
> 
> // hey, who ever heard of a sum of strings?
> StringBuffer sb=new StringBuffer();
> sb.append("abc");
> sb.append(123);
> return sb.toString();
> 
> ?

No I wouldn't prefer these.
I prefer format("abc",123); :)

> 
> I mean, compared to almost everything else in programming, is it really 
> so hard to grasp/learn/remember/know/whatever that 0 and null evaluate 
> to false, while everything else evaluates to true?

No, the problem is and never was in neither grasping nor learning nor 
remembering this behavior. The problem was that some people see booleans 
as mathematicians, and in math bools can only be true or false, and can 
only be a result of operations like <,==,>=, !is, ...

> 
> 
> xs0
> 
> *) this could be called a little-endian string :)

Cool!