Re: Definition of table.insert

[Alexander Gladysh <agladysh@...>]

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.

What I had in mind is something along these lines:

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()

For some reason you want new tasks to be inserted *somewhere* in the
middle of the queue. That is, not necessary strictly in the middle
(strange, but plausible):

table.insert(t, math.ceil(#t / 2), get_next_task())

To make nils in the queue make more sense, let's add the condition
that 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). This
way you already have to deal with nils, and inserting them does not
look not so bad.

(I do not say that this particular example is useful or the best way
to do it though. I'm just saying that table.insert(t, n, nil) may make
sense.)

Alexander.