[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Definition of table.insert
 
- From: GrayFace <sergroj@...>
 
- Date: Sat, 08 Jan 2011 23:23:07 +0600
 
On 08.01.2011 16:28, David Kastrup wrote:
insert(t,n,somefunction(...))
where somefunction may decide not to return a value.
Currently, if that function returns no value, table.insert(t, n) would 
insert 'n' as the last element of 't'. So, your proposal would change 
more than just a small case of 'nil' value.
However, it would be really nice to have the thing you're talking about 
with any number of values returned by 'somefunction', not just 1 or 0. 
Here's how I'd like 'insert' to work:
table.insert(table, pos, ...)
Inserts values '...' at position 'pos' in 'table', shifting up other 
elements to open space, if necessary. Returns number of elements 
inserted (i.e. the number of parameters passed as '...'. Alternatively, 
it could be made to return index of the last inserted element).
So, this is backwards incompatible with |table.insert(t,x). There's| no 
special case for 'nil'.
1) The natural use case is when many elements must be inserted. 
Currently this can be done with a custom implementation or by inserting 
elements 1 by 1, thus slowly.
2) Here's another use case I really like:
local t = {}
t.n = table.insert(t, 1, f())
Example:
function f()  return nil, nil  end
-- =>  t = {n = 2}
IMO, it's good the way it is. Less checks mean more code and
documentation elegance.
Care to explain?
It's good when logic of a function is simple, like "table.inset(t, n, x) 
inserts x at position n in t". It's perfectly easy to explain and 
remember. In current implementation there is a special case of 
'table.inset(t, x)' and turns out both of us forgot about it. I for one 
just found it in the manual while thinking about 'insert' with variable 
number of values.
Your suggestion about a special treatment of 'nil' is similar in that 
sense. It complicates the logic of 'insert' and would be rarely used.
A suggestion to throw an error in case of 'nil' adds little complication 
to the logic and detects a potential error. The error should be rear, 
but not consistently reproduced, so I'm in a bit of a doubt. Note that 
table.insert is also capable of creating holes when 'n' is non-integer 
or a big negative value.
--
Best regards,
Sergey Rozhenko                 mailto:sergroj@mail.ru