[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: API: luaL_typename and lua_setmetatable
- From: "John Hind" <john.hind@...>
- Date: Wed, 29 Jan 2014 12:12:28 -0000
I'd like to recommend a couple of minor tweaks to the 'C' API:
1. Deprecate luaL_typename.
Reason: it is too easy to write 'name = luaL_typename(L, lua_type(L, 1));'
when you mean 'name = lua_typename(L, lua_type(L, 1));' or 'name =
luaL_typename(L, 1);' and get a very subtle and hard to find bug!
Discussion: why does lua_typename need the state parameter? It is just a
constant lookup. It is not for consistency, because lua_upvalueindex already
breaks the rule that the first parameter is always the state. If
lua_typename did not take the state then luaL_typename would be safe because
the compiler would catch the error.
2. Separate the two use cases of lua_setmetatable.
Reason: it is too easy to accidentally set a type metatable when you mean to
set a value metatable on a table or userdata. For example, you have a
function which generates a userdata or nil, later you use lua_setmetatable
on the result and end up setting a type metatable for nil with baffling
wide-ranging consequences! Also, it seems kludgy when you do intend to set a
type metatable that you have to create an exemplar value just to identify
the type.
Discussion: suggest that lua_setmetatable should error if the value is
neither table nor userdata type. There would be a new lua_settypemeta which
takes a type constant rather than an exemplar value. The problem does not
exist in Lua because setmetatable only works on table values.
I know C programmers are assumed to be responsible adults who know not to
run with scissors, but that is not a good reason to make scissors
unnecessarily dangerous! I confess to having wasted inordinate amounts of
time finding both these bugs in the wild, so this is not just a theoretical
concern!
- John Hind
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com