 |
lua-l archive |
|
|
||
|
Am 16.07.2016 um 10:47 schröbte steve donovan:
On Fri, Jul 15, 2016 at 10:54 PM, Michael Nelson <mikestar1313@gmail.com> wrote:For me, this thread is just making tables too complicated. They only thing I might like to see changed in the table library is to make table.pack and table.unpack symmetric, as has been discussed upthread.That's my position as well - never had a problem once I learned to avoid holes.
I doubt that anyone who took part in this discussion has not yet learned to avoid holes in arrays by now. I am a bit surprised that there were experienced Lua coders who didn't know about the `table.pack()`/`table.unpack()` asymmetry (it has been discussed extensively when `table.pack()` was added to Lua), but now that everyone on this list has been made aware, this problem is solved as well. Personally, I never had a problem with `table.unpack()` (or its Lua 5.1 equivalent) once I learned to explicitly pass the value of the `n` field to `table.unpack()`. Both problems are mere inconveniences that experienced Lua programmers can easily work around. A solution to the arrays with holes problem automatically also solves the asymmetry problem, but it seems we are currently stuck in that regard. So let's try to get rid of the asymmetry problem independently:
I think that people expect symmetry between `table.pack()` and `table.unpack()`, because they are both in the same namespace, their names suggest some form of inverse effects, they are often used together, and the return value of `pack()` matches the expected arguments of `unpack()`. Now, we could make them symmetric, or break the expectation of symmetry. My suggestions:
1. Rename `table.pack()` (or `table.unpack()`).2. Make `table.pack()` return `n` as a separate return value. This would make it clear that only the table functions that explicitly take end indices work on packed tables. 3. Make `table.unpack()` check for an `n` field. But what about the other table functions? Should `pack()` and `unpack()` move out of the table library? 4. Set a metatable with `__len` on packed tables. Again, what about the other table functions (mostly `insert()` and `remove()`)?
IMHO, of those options no. 2 is the cleanest because it doesn't lead to further inconsistencies.
Anyway, I've decided to sidestep the issue and use `.n`-style tables for arrays in my own code. I've linked to the modified standard table library else-thread, and I've started to rewrite my other module code to always set `.n` on new arrays, and to check for `.n` before falling back to `#` or `luaL_len`. It's mostly compatible with Lua's sequences as long as no holes are involved, and I don't have to wait for Lua to figure things out ...
Philipp