Re: nil isn't as unique in Lua 4.1
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: nil isn't as unique in Lua 4.1
- From: Peter Shook <peter.shook@...>
- Date: 2002年1月10日 22:43:18 -0500
Roberto Ierusalimschy wrote:
>
> On 2002年1月10日, Eric Ries wrote:
>
> > I'm afraid that, if Lua goes down this path, we will have the need for
> > Perl6's "defined-shortcut-operator" which works "like || but with a twist"
>
> I think that, more often than not, you know what type of object you
> are expecting. So, if you are expecting numbers, or tables, or strings,
> you still can use the "or" to select the first "defined" value.
>
> In the few cases that a false is among the possible outcomes, then we
> will have to go through the pain of writing "if a == nil then ... ".
I'd agree that most of the time it isn't a big deal. I'm just a little
saddened that the once beautifully simple 'or' operator is now somewhat
tarnished, and there isn't really a compelling reason or need for a
boolean type.
I look at lexically scoped and eventtable and I think "WOW, that's
great. That will fix a whole bunch of nasty things in my code." I look
at false and I thing "What for?". I guess false just isn't that useful
for me. I just hope you don't go and add 0, "0" and "" to the list of
false values.
One other thing I find peculiar is that the second argument of concat
and eventtable cannot be nil (or false).
This is a pain when you want to wrap concat in another function. You
must say:
function join( t, sep )
-- whatever other stuff
sep = sep or '' -- because nil won't work
return concat( t, sep )
end
Or if you want to save and restore the eventtable for some reason.
function dosomethingspecial( t )
local et = eventtable(t) or {} -- need 'or {}' because nil won't work
eventtable( t, somethingnew )
-- whaterver other stuff
eventtable(t,et)
end
- Peter