[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: Different shades of false
- From: "Dolan, Ryanne Thomas (UMR-Student)" <rtdmr6@...>
- Date: Thu, 2 Mar 2006 11:23:39 -0600
Exactly. The only problem with nil/false is that people use these values incorrectly. nil is by no means synonomous with false, so it makes sense that nil ~= false. Being false and not defined are two very different states.
And the proposal that all types should have true/false values seems strange to me, as anything with true/false evaluations is by definition a boolean, which Lua of course already has. Would it make sense at all if "" == 0?
So long as you take the convention that nil means something like "undefined" then everything makes sense the way it is.
assert (bar ~= nil);
if bar == true then
print "true";
else
print "false";
end;
-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br on behalf of Adam D. Moss
Sent: Thu 3/2/2006 10:59 AM
To: Lua list
Subject: Re: Different shades of false
Alen Ladavac wrote:
> Why not getting rid of false altogether?
I guess because nil and false just aren't the same
thing with different types. For comparison purposes
they pretty much serve the same function, but as table
values (and keys!) they're semantically very different
things, not just differently typed.
(I use 'false' values in tables where a 'nil's implicit
removal of the corresponding key would not mean what I want -
particularly in configuration management where setting
an option to false is different from setting it to nil,
where the latter case simply says that this configuration
option doesn't exist and is therefore undefined/defaulted.)
--adam
<<winmail.dat>>