lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



The problem with 'setn()' is, it demands some kind of "under the hood" knowledge about how Lua table management works. Such as your usage scenarios. To me, it's perhaps the last mohican of a C-like management approach, where the programmer needs to 'know' what happens. Otherwise, strings and gc, Lua just "does the right thing".

For this reason, I won't miss it at all.

-ak


4.11.2004 kello 18:17, Mark Hamburg kirjoitti:

I like this idea, but I do use table.setn when clearing the contents of a
table. It is also useful when creating arrays that will be unpacked but
which might include nils.

Mark

on 11/4/04 7:08 AM, Roberto Ierusalimschy at roberto@inf.puc-rio.br wrote:

table.insert is too slow and we all agree that is would be good a
standard way to do that operation (insertion at the "end" of an array).

I have a proposal for a new operator (after all these years): "*t" would return the "size" of table t. With that operator, the insertion of a new
element in an array would be written as <<t[*t+1] = v>>. To remove the
last element, we would write <<t[*t] = nil>>.

That operator would deprecate table.getn and table.setn. getn(t) would
become *t; setn(t) would vanish. (Those operations have become quite
complex; they are slow and difficult to understand.)

The definition of *t is also a little tricky, but simpler than the
current getn. To allow an efficient implementation, *t cannot return
the largest integer index in the table. (That would demand a linear
search.) Instead, it returns an index i such that t[i] is not nil and
t[i+1] is nil. For arrays without holes, this is the largest index.
For arrays with holes, this is a "possible" end. (This value is what
getn returns in Lua 5.1w when there is no setn.) With that definition,
we can implement *t with a binary search right into the array part
of the table. This is quite efficient. Even for very large tables
(10Mega elements) an insertion <<t[*t+1] = v>> is *much* faster than
table.insert.

-- Roberto