|I suggested __type() as an extension to type() some time ago, for other reasons. In fact, it's an odd omission (to my mind), given that we have __tostring() and others. This appeared to have little support, so I went ahead and created my own version for my current project.|
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. In EVERY other part of the language, this distinction can be ignored because the two are made equivalent by the language design: viewing a table as having an infinite number of elements, most of which are nils; the same for function arguments and return values etc.
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).
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).
I also want to address a possible confusion about names: I used the word "empty" to mean a distinguished value that had no special properties other than it was different from all other values; this was my approach to solving the "empty" problem (good or bad though it might be). However, I realize some posters have assumed by "empty" I meant a property of a table element (which is one way to address this, of course). In my head, "empty" would evaluate as "true" in a boolean context for example, so in reality "empty" is not a good name; to my mind "empty" is more like NaN.
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)?
2. Assuming #1 is "yes", would this be useful as a standardized technique so that everyone uses the same convention?
3. Assuming #2 is "yes", what form should this standard technique take?
My apologies for the long post, I just wanted to clarify a few things in my head.
On Jul 5, 2013, at 11:40 AM, Andrew Starks <firstname.lastname@example.org> wrote: