Re: Definition of table.insert

[Alexander Gladysh <agladysh@...>]

On Sun, Jan 9, 2011 at 08:42, Alexander Gladysh <agladysh@gmail.com> wrote:
> On Sun, Jan 9, 2011 at 02:36, Henning Diedrich <hd2010@eonblast.com> wrote:
>> On 1/8/11 12:00 PM, Alexander Gladysh wrote:

>> You can not be sure what user meant by this. Perhaps he does want to insert
>> nil.

>> Note that even when this behavior is expected, this code is not
>> necessary bugged:

>> insert(t,n,somefunction(...))
>> insert(t,n,somefunction(...))
>> insert(t,n,somefunction(...))

>> It's about the n:

>> if you say 'not necessarily buggy' that is hedged enough to be true.

>>  But already your 3 line snip can lead to insert() making replacements
>> instead of pushing existing values up.

>> You could for only /one/ nil, /still/ end up with a table only holding 1
>> value, not 2.

> Well, but what if that is what I want? That is why I'm saying that you
> can't try to outguess the user.

<...>

And if you drop n, it makes even more sense:

Say I have a task queue in a table (plausible).

t = { }

There is a function that returns the next task or nil if no tasks are
currently available (plausible):

get_next_task()

We do not care much where new task would be inserted, but it better be
closer to the end of queue:

table.insert(t, #t, get_next_task())

At random intervals of time random tasks are taken from the table
(let's say that the t is weak-valued, and the tasks just expire — or
someone explicitly nil them).

This way new task will get to the first hole available, and the table
will not be resized grow without need. Task processing algorithm
should be aware about nils in the queue though (maybe it uses pairs(),
that may explain why order does not matter).

I actually something similar in practice (not with tasks though, and I
did not try to *insert* /or append/ nils).

Alexander.