lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Tue, May 4, 2010 at 1:35 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> 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
>
>


I have to admit I hadn't considered that exposing lua_createtable()
might make performance *worse* rather than better. Is that just
because overzealous newcomers might assume they have to preallocate
all the time and overuse the function, or is it a more insiduous thing
that can happen even if what you're doing seems initially sensible?

Also, I seem to remember that one of the changes being considered for
5.2 was to (conceptually) break the debug library into two halves.
Currently, in 5.1, the whole library is covered by the recommendation
"you should *never* use any of these functions in real final code,
*only* for debugging purposes". But in 5.2, the idea would be that
*some* functions are still covered by that, but some would instead be
"you *can* use these, in modules and such, but you can hurt yourself
if you use them wrongly - be careful and make sure you know what you
are doing". In other words, functions that are intended for more
advanced/low-level stuff, rather than exclusively for debugging. If
this is still the case (and I'm not misremembering it in the first
place), and the main problem with createtable is that people might use
it badly, how about making createtable a part of that?

-Duncan