[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: new "empty" value/type in Lua?
- From: Coda Highland <chighland@...>
- Date: Mon, 1 Jul 2013 15:04:44 -0700
On Mon, Jul 1, 2013 at 3:00 PM, Dirk Laurie <email@example.com> wrote:
> 2013/7/1 Roberto Ierusalimschy <firstname.lastname@example.org>:
>> Much more serious, for me, is the incompatibility that t[#t] = nil will
>> not "pop" elements form a list (and. of course, the extra complexity).
> Exactly. Deletion by assigning nil is too ingrained in existing Lua
> programs to be replaced now.
> The need is not for nil to change its nature. The need is for table keys
> to be classifiable as legal or illegal before they are used. The length
> function would work on legal keys, not on keys in use. The proposed 'has'
> function would simply distinguish between legal and illegal keys.
> One possible mechanism could be a metatable entry '__has'. If this
> is nil, we are back in the present situation, so no incompatibility.
> If this is present, __newindex will not assign and __index will not
> retrieve illegal keys.
> If `__has` is a table, then 'has(tbl)' looks in it for the key. If it
> is a function, 'has(tbl)' calls it and returns the result. If it is
> a number, 'has' accepts all integer keys between 1 and `__has` and
> # returns `__has`. To create a fixed-size, no-holes table that can
> take 100 entries, all you need to do is
> By all means offer syntactic sugar `tbl=array(100)` for this. The
> array part would be allocated to take 100 entries. Nil would still
> be used to identify currently unused keys, but the array would not be
> shrunk even if less than half full.
> The proposed 'delete' function does not seem to be as useful. Just
> deleting the present value can be done by assigning nil, and permanently
> changing the legality of a key should not be as easy as calling a
> standard library function. It should require explicit reassigning of
I'll be honest, that sounds somewhat overengineered, and the number of
lookups that introduces sounds like a performance drain because you're
making the dot operator itself more expensive. A "sticky keys" tag
akin to the "weak values" sounds a lot cleaner because it limits the
scope of the effect and can be handled within the VM itself instead of
needing to inspect Lua-side data or invoke Lua-side functions.