Re: Different shades of false
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Different shades of false
- From: "Alen Ladavac" <alenl-ml@...>
- Date: Thu, 2 Mar 2006 17:49:52 +0100
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