Re: [PROPOSAL] a new function: table.proto()

[Roberto Ierusalimschy <roberto@...>]

> Isn't this implementation detail already indirectly exposed by the
> existence of pairs/ipairs? I'll bet that not one single real-life
> application wouldn't experience some problems with tables if the
> implementation did change.

pairs/ipairs has *nothing* to do with the fact that tables has two
parts. This fact is completely hidden in the implementation, and there
is no way for a Lua program to change its behavior depending on this
implementation (except for performance). Even the lua_createtable
function, that exposes this detail, does not depend on it (again except
for performance).

(So, except for performance, not one single real-life application would
experience any problem with tables if the implementation did change.)

Our reluctance to expose createtable to Lua is that, in the same way it
can improve performance if used wisely, it can hurt performance if not
used properly. As stated previouly, the difference between a proper use
and an improper one is only visible through performance; it cannot cause
any functional diference at all.

-- Roberto