Note both tables SHOULD be identical for all purposes but those of foreach().
Indeed, it appears like all table-related functions are completely unaware of possibility of non-sequential indexing, to the point where it would appear like it would be seem like a good idea to keep a separate table (collection) for indexes.
Also, it's okay to do c={[0]=0,1,2} to initialize the table in the second case.
foreach() and all() really need to behave just like pairs(). The current implementation only does the 1..n array part for dubious reasons, and I haven't seen any carts in the wild taking advantage of the fact that you can 'hide' non-iterated values inside a table because of this. So, unless I discover a good reason to keep the current behaviour, I'll look at iterating over all elements like pairs() in 0.1.2 (or maybe 0.2 if it turns out to be tricky)
pls pls pls allow us to get the keys with pairs() too. that would be awesome.
The other reason to keep foreach is that pairs() doesn't guarantee ordering of tables. unless in your implementation you do something like returning the sorted int keys first, then return the other types of keys. dunno tho.
another thing - del() doesn't renumber the remaining members of the collection, so you get a weird collection where the first member is nil but the others exist somehow.
I can hammer nails with a wrench, too!
That came out a bit strong. Sorry.
[Please log in to post a comment]