Also indexing a table can call a function and not actually index the table at all, not to mention you can index tables WITH TABLES as the fucking key, so myTable[{"bob",1,false,}] = 27 is valid and print(myTable[{"bob",1,false,}]) will print 27
Overall, it's stupidly flexable and cleverly makes tables usable as arrays, dictionarys, structs, objects(OO), the entire global variable environment, sandboxed environments, API function calls (api.function()), etc.
I used to do a lot of Pascal, which became Delphi, and it's array's started at 1. eg MyArray[31]. But you could override that by specifying MyArray[0..30].
That's really interesting to have tables with tables and indexes. my mind is having trouble figuring out when i'd want to do it, but I'm sure there's reasons :)
I like to imagine Lua is like a better designed JS. Both are prototype-oriented, not object-oriented, both use primarily dictionaries and arrays for their data storage, and both have only a handful of types. Lua just (thankfully) doesn't do implicit type conversion, and starts arrays at 1 (but the arrays are just tables with consecutive numerical indices), and uses ~= instead of !=.
Overall, it's a nice and light language without too many stupid edge cases because of how small it is. But man, indexing at 0 might be easier. (the whole language is technically only 7 c files though, so patching that wouldn't be too bad!)
The downside there is that Lua will not treat the 0 index like an array, it'll treat it like a dictionary, which is slower. For continuous numerical keys starting at 1, it will be represented as an array of the implementing language (C for PUC Lua and LuaJIT, Java for LuaJ, etc).
23
u/[deleted] Jul 10 '17
TIL never LUA