Re[2]: Different shades of false

[Alen Ladavac <alenl-ml@...>]

adam wrote:
> Pragmatically I'm not really interested in other values
> coercing to false but if it's cheap to implement then the idea
> doesn't completely horrify me.

First of all, yes, its cheap and simple. It took me much more to even
write the original post, than it took my coleague to implement this.
:)

Also, I get you why removing false while keeping true is evil. In your
config example, you _must_ use ~=nil. I argumented that reasoning in a
previous post in this thread. But my conclusion on that is not to keep
the things as they are, but to extend them for better orthogonality.

to comment on the other posts....

Those notes about {} ~= {} was certainly one of the kind of ideas that
I was trying to solicit. That was very useful, and gives strong
arguments why this should not apply to tables.

Still, about the case with numbers and strings, it looks to me like a
lot of people are getting it wrong. I'm not saying that it should be
false == 0. Quite on the contrary. The important thing here is that
false ~= nil, yet they both make an if statement take the else route.
So, we have two different types (yes, nil is a type, at least it was
the last I checked the spec), both taking an if statement down the
else route, so the original orthogonality is broken. And backwards
compatibility is broken as well. I propose to add more orthogonality
while not breaking any (sensibly correct) code, by adding one
logically false value for each type where it makes sense. (Note that
this does _not_ make 0 == false, or something like that.)

Sticking to the backwards compatibility here doesn't seem to make
sense. The moment boolean type was introduced, all previous scripts
that used "if table[key]" were broken, if a boolean value was entered
there. Adding more orhogonality here is not going to break anything
more. It is rather more likely to unveil hidden bugs.

Alen