 |
lua-l archive |
|
|
||
|
Am 12.02.2016 um 18:36 schröbte Peter Aronoff:
Philipp Janda wrote:I'm sure we all agree that a general table should be able to hold any string key including ones starting with _ + uppercase letter. However, a module table is not a general table, and there already has been Lua-Rio code in Lua 5.1 that used the `_M`, `_NAME`, and `_PACKAGE` fields in module tables, so the reservation of those names probably does not apply to global variables (and the registry) only.But those tables and the tables that my module exports are by definition distinct, aren't they? I'm worried that I'm missing something painfully obvious, but I don't see how a clash could occur.
I just wanted to mention that there is official code out there that sets fields with reserved names in module tables. At the moment there will be no clash, because `module` is deprecated (5.2) or gone (5.3), and it didn't set `_VERSION` anyway. But I take that as a hint that you use reserved names in module tables at your own risk.
A user of my module has
to require the module and save the table it returns, using an identifier.
That identifier holds one specific table and is distinct from any other
table from Lua-Rio or any other code.
More concretely:
local split = require('split')
if split._VERSION == 'whatever' then
whatever()
else
whatever_else()
end
How can the _VERSION identifier in the one table ever clash with one in
another table?
It won't clash with fields in other tables, but it could clash with future Lua code, because as suggested by the implementation of the `module` function `_VERSION` is a reserved name in module tables.
While we are talking standardization: 1) LPeg (which I consider semi-official) has a `version()` function.2) Is a string (especially if it also contains non-version info like the package name) really the most useful representation for a module version? Should we maybe make the semver module[1] the most often used dependency in the LuaRocks universe?
Philipp [1]: https://github.com/kikito/semver.lua