table library respects metamethods
Closed this issue · 13 comments
The table library should not use raw accesses.
@hishamhm, @daurnimator, @zhaozg
The table library is almost complete (only table.sort missing for now). More tests are welcome! However, since pretty much every function in the table library has to be replaced anyway, we could use the same approach as for the utf8 module, and just use ltablib.c from the Lua 5.3 sources as is (I'd just have to turn the lua_rawget/lua_rawset macros from the c-api into real functions). On the other hand, the utf8 functions could probably be implemented in pure Lua, too.
What do you think?
Never mind (there is a problem with Lua 5.1 not respecting the __len metamethod on tables), the table library stays in pure Lua for now.
Never mind (there is a problem with Lua 5.1 not respecting the __len metamethod on tables), the table library stays in pure Lua for now.
Why does that matter?
You can always check __len from C...
You can always check __len from C...
But the source code of the table library didn't (or rather our lua_len implementation for Lua 5.1 didn't). I changed that, so the option of using ltablib.c from the 5.3 sources is on the table again (no pun intended).
Anyhow, table.sort in pure Lua is available as well by now.
Well, since parts are already written in C, I don't see a problem in having it either in C or Lua.
Speaking of tests, a crazy idea would be to see how much of the standard Lua test suite for 5.3 one would be able to run in an earlier version using compat :)
Well, since parts are already written in C, I don't see a problem in having it either in C or Lua.
That's the point, I think utf8 could be implemented in pure Lua as well (string packing is another story, though) ...
Is there a reason to prefer Lua code over C code (for the user of compat53)?
@siffiejoe I don't know... Windows users who shudder at the idea of setting up a build environment and compiling C code?
Ah, and pure-Lua might run faster for LuaJIT users, but further tests would be required.
I can imagine people wanting to use pure lua libraries inside a game or framework where they can't load C code...
For my use cases, I don't really care/mind; I mainly use the project for new C functions :P
Most table functions aren't compiled in LuaJIT anyway, so I've added ltablib.c from the Lua 5.3 sources as a C module. I'll keep the pure Lua code as a fallback in case loading the C module fails.
(I think users of a game or a framework are stuck with one specific Lua version most of the time, so a compatibility module makes no sense for them ...)
(I think users of a game or a framework are stuck with one specific Lua version most of the time, so a compatibility module makes no sense for them ...)
I was imagining someone wanting to use a general pure lua module (e.g. luatz), that might be written against new apis (e.g. table.move): the user might be stuck on lua5.1, so they load compat-5.3 first?
Point taken.
We now have string packing as a binary module, so I'll leave the binary utf8 module alone as well.
Running the Lua 5.3 test suite proves to be rather complicated: I had to disable test code with integer division operators, bit operators, large integers, and utf-8 escape sequences. The table, utf8, and string packing functions pass the remaining tests, but those are the pieces that I took from the Lua 5.3 sources almost unmodified. Testing the rest this way is too much work for me at the moment ...
I think I'm done for now, so I'll change to a more reactive mode of development.
@siffiejoe wow, awesome!! I guess this means it's time to tag it 0.1 and announce it to lua-l, then. Will you do the honors? :)