 |
lua-l archive |
|
|
||
|
Am 01.07.2016 um 03:01 schröbte Jonathan Goble:
The fact that this thread has ballooned into nearly 80 emails and is still being debated suggests to me that perhaps we need to stop trying to make tables do a job that they weren't designed to do, and instead create a new array type separate from tables that is designed to do that job. Most languages have two distinct types for sequences and associative arrays. Lua has just one type, the table, which is really good at the latter, but doesn't do a very good job at the former. The ongoing discussion proves that there is a need for a real sequence type capable of holding `nil`, but I just don't think there is a good, clean way for Lua, as it stands right now, to do that short of creating a new type for sequences and deprecating tables for that purpose (they would remain useful for associative arrays, of course). A new type would have many advantages, chief among them elimination of the need to store the length as a field in the table or metatable (since the length would now be known and tracked by the C internals),
One could add a table subtype (much like the integer subtype for numbers) and stick the size field to the end of the table structure like the payload for a userdata. This way we could re-use most of the table implementation. In fact, arrays would behave exactly like regular tables except when array-like behavior conflicts with generic table-like behavior.
Of course the `#` operator (and as a consequence the `table` functions) should raise an error when applied to a non-array table without `__len` ...
and elimination of the question of how to set the initial length from a constructor (since array constructors probably wouldn't allow explicit keys/indices).
Separating array literals and hash map literals might be worth considering anyway (if Lua chooses to set an initial length in the future).
I really think that this is the best way forward.
There are few smaller steps we can make: * Solve the `pack()`/`unpack()` symmetry problem.* Enhance the table library to allow non-sequence based array implementations by adding a library metamethod `__resize` or `__setsize`, so that `table.insert()` and `table.remove()` can adjust the array sizes accordingly (`table.move()` is more complicated).
Philipp