 |
lua-l archive |
|
|
||
|
Am 28.06.2016 um 08:52 schröbte Tim Hill:
On Jun 27, 2016, at 11:07 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote: 2016-06-28 5:29 GMT+02:00 Tim Hill <drtimhill@gmail.com>:To be honest I’ve never liked the use of “n” as a pseudo-length. First, it’s inconsistent (collides with use of #). Second, it’s hi-jacking a perfectly normal user key with very little notice (why wasn’t a reserved “_N” used?).Why must such a key match "[_%a]%w*"? Can't we reserve tbl["#"] for the purpose? With the semantics of "__len" extended to treat that as a first fallback? I.e.I was just going by the Lua ref manual that states that leading underscore + upper case are reserved for Lua use, hence “_N”. “#” is interesting, but technically it’s a valid user key so could collide with other things (I’m sure someone has built a token parser where the tokens are table keys).
The reserved key `_N` isn't much better than `n`. A data table that stores arbitrary string keys, possibly from user input, can *obviously* also contain keys like `_N` or `n`. If you want to prevent accidental name collisions with the table length field key, you'd have to use a unique userdata or table and maybe make it available as `_G._N` (where reserved names actually matter). The resulting `t[_N] = 3` syntax is still not that bad. However we should probably also ban all user-supplied integer keys because they may lead to undefined behavior with the length operator. Or we could do what we do now and just not pass tables with arbitrary/unknown keys to functions that expect tables with a certain structure (like sequences) ... That's the price you pay when you use the same data structure to store user data and program data.
—Tim
Philipp