 |
lua-l archive |
|
|
||
|
1) On the one hand, it seems arbitrary to say that four non-truth values is better than two.
A friend of mine said wisely that it might not be better, but it certainly is not worse. :) As having two of them is really non orthogonal to start with.
From a purist standpoint, it would make sense, I think, to insist on exactly one.
But if nil is not that value, you'd be in serious problems as lua relies on the notion of not having runtime errors due to nils, and nil not being true saves it there. One solution would be to banish "false" from the boolean type.
On the other hand, false is obviously not true, and (I think) nil is likewise obviously not true. So if you were going to pare it down, you'd need to get rid of one or the other. I, personally, don't want to get rid of either. So I think we're stuck with more than one non- truth value.
Why not getting rid of false altogether? Isn't that much more orthogonal than the current situation? (I mean, I'd rather seek orthogonality in the other direction, but I'm interested to know whether you have some reasons for this.)
So, then...why not go hog wild? If we've got two, let's shoot for one 'false' value for each primitive type. nil, false, 0, "", and (for consistency) {}.
You are right. Empty table should be considered as well, for consistency.
Now it's easy to tell if a value is 'empty', but harder to tell if it's present than before.
It is not any harder. It is equally as hard, because false is already deceiving you. I'd just like to point this out by requiring foo~=nil to be used for presence, as just foo is not correct starting with lua 5.
2) I'd like Lua to match C for easier interfacing.
Really, this has more to embedded scripting in general than with C. I'm confident that everyone perfectly understand the concept of 0=false, 1=true, and that it is natural for that to be used in configuration scripts and similar. In all our previous projects, both in-game console commands and configuration scripts support a notion of booleans as 0/1. People are used to type some_config_var=1 or =0. If =0 started to _enable_ stuff, we'd have a lot to explain to the users. Duck-and-cover kind of explaining. ;)
One addition to this argumentation that now becomes obvious to me: As I see it, if we want orthogonality, then it is either (a) add one falseness for each type or (b) remove false from boolean type. Now, removing false from boolean gives a weirdness of not be able to verify whether a boolean variable is present. In this line, I only see more arguments for (a).
Alen