[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Empty? No. Array? No. Has? Yes.
- From: Patrick Donnelly <batrick@...>
- Date: Sat, 6 Jul 2013 10:02:41 -0400
On Fri, Jul 5, 2013 at 3:40 PM, Tim Hill <firstname.lastname@example.org> wrote:
> As far as empty/null/nil/array holes is concerned. My root cause analysis
> comes down to the fact that nil is subtly overloaded. The language succeeds
> in hiding this overloading in all but one place: when an array element is
> assigned nil. At that point the overloading becomes apparent; nil means both
> "no value" and "delete", one a noun, one a verb.
No, no, no. There is no concept of "delete" in Lua. The assignment
means that future indexes with the key will return nil. It means
> In arrays, however, this hiding breaks down, because "no value" and "delete"
> cannot be split apart; I cannot use nil *inside* an array. All the
> suggestions so far (including my own "empty" value) come down to being able
> to split apart the idea of the "size" of an array from the presence of an
> "empty" element (however you define empty).
This abuse of nil really needs to stop. Arrays in Lua are dynamic and
necessarily use nil to signal the end. You can't have holes in your
array: part of the definition of the data structure (not just in Lua).
If you want an "empty" value, *make one*. There have been so many
suggestions on how to build your own that this continued discussion
has become tired and frustrating. If anything is clear, the language
does not need to be changed to accommodate you.
It's not Lua that is overloading nil, it's *you*. Your idea of a "lack
of useful value" is distinctly different from Lua.
> So how DO you define "empty" (assuming there is case for it at all)? Roberto
> suggested "false", but in my particular case i'm already using booleans
> within the table. And numbers, and strings etc. So my solution was to create
> a unique "empty" value using light userdata, which was all I needed. This
> worked better for me than special array properties (table.has() etc), as I
> could also pass "empty" as a function argument/return value. The empty table
> trick works within a given Lua state, but, again, I wanted to be able to
> tunnel empty values between Lua states, where each would NOT share the same
> empty table (whereas they CAN share the same distinguished light userdata).
Sounds like you have the solution all worked out then. Use the light userdatum.
> So to my mind this long discussion comes down to three questions:
> 1. Is there a need for an "empty" element within an array (where "empty" as
> a concept is tbd)?