37 replies to this topic

[Zudo]

How to use tables

(and use them well)

Welcome to this tutorial about using tables. This tutorial is split into parts:

Part I - Creating a table

A table is a list of values, which are all stored under one variable.
In Lua, a table is an associative array, which means that any values stored in one are referenced by a key, which can be a number, string, boolean or even another table!

To make a table, simply do this:

local myTable = {}

The variable myTable is now an empty table.

Part II - Numbers as keys

If you already have a table, you can insert a value referenced by a number into the table with one of these methods:

-- This...
myTable[1] = "This is item 1 of the table"
-- ... does the same as this
myTable:insert(1, "This is item 1 of the table")

You can then refer to this value as:

print(myTable[1]) -- Prints out "This is item 1 of the table"

You can replace 1 with any number you like, and it will still work. Note that myTable:insert() will shift the positions of the other values in a table, whereas referencing the table directly (myTable[1] = "...") will overwrite the value at position 1.

Part III - Strings as keys

If you are creating an array with no specific order (e.g. a username and password table) you can also use strings as a key:

myTable["ZudoHackz"] = "MyPassword"
myTable["SomeoneElse"] = "SomePassword"

You can't use myTable:insert() with strings (I think). To reference a value, you can just do:

print(myTable["ZudoHackz"])
-- Or
print(myTable.ZudoHackz)

Part IV - Initializing a table with data already in it

local myTable = {}
myTable[1] = "blah1"
myTable[2] = "blah2"
myTable[3] = "blah3"
...

This works, but it is quicker and shorter to do this:

local myTable = {"blah1","blah2","blah3"}

If you create a table like this, myTable[1] would be set to "blah1", myTable[2] would be "blah2" etc.

You can also do this:

myTable = {[1] = "blah1", [2] = "blah2", [3] = "blah3"}

If you do it this way, you can change the order easily:

local myTable = {[3] = "blah1", [2] = "blah2", [1] = "blah3"}

Or even do this:

local myTable = {[1] = "blah1", [6] = "blah2", [300] = "blah3"}

This also works with anything else as a key:

local myTable = {["one"] = "blah1", ["two"] = "blah2", ["three"] = "blah3"}

Part V - Using tables

Tables are used for storing similar information. But, they can also be used for other things, like:

Capturing return values

Some functions, like os.pullEvent() return different amounts of return values. You could do something like this:

local a, b, c, d, e = os.pullEvent()
print(a)
print(B)/>/>/>
print(c)
print(d)
print(e)

but you still can't be sure you have saved all the return values. However, a setup like this:

local myEventData = {os.pullEvent()}
for _, value in pairs(myEventData) do
print(v)
end

would definitely capture all of the values, and definitely return them all. More on the for loop later. Anyway, if you put the function call in curly { } brackets, it will return a table. myEventData[2] in the second example is equal to b in the first example.

Please read

IP.Board screwed up the third line of the first example in this section. It is print b but with brackets, rather than spaces.

This isn't really a use of the table, but it is very useful to learn about

Iterating through a table

With the pairs() function, you can iterate through a table. Here is an example:

local myTable = {"blah1","blah2","blah3"}

for key, value in pairs(myTable) do
print("The value of the key " .. key .. " is ".. value)
end

This piece of code repeats 3 times (there are three values in the table) and prints:

The value of the key 1 is blah1
The value of the key 2 is blah2
The value of the key 3 is blah3

So this can be very useful. How about this?

local myTable = {"blah1","blah2","blah3"}

local function isInTable(table, value)
for _, v in pairs(table) do -- Use _ if you don't need that return value.
  if v == value then
   return true, k
  end
end
return false
end

isInTable(myTable, "blah1") -- Returns [true, 1]
isInTable(myTable, "blah2") -- Returns [true, 2]

isInTable(myTable, "blah3") -- Returns [true, 3]
isInTable(myTable, "blah4") -- Returns false

So iterating through tables is very, very useful.

Thank you for reading this tutorial! Please point out any mistakes, and advise me on using tables even better! />/>

-Z

[theoriginalbit]

There is a lot that you've missed. You haven't pointed out anything such as mixing indexed and key/value elements, negative indexes, iterating through tables, both with a numerical for loop and a generic for loop (pairs/ipairs). The advantages of each type of loop (incremental/ipairs/pairs), especially when dealing with custom indexes such as a table that only contains indexes 1,2,4,17,700. There are various other improvements along these lines that you could make.

I think that maybe explaining and/or showing an example of how tables can help us capture all return results from a function call, or all arguments in a vararg function.

You also don't state why it is better (efficiency-wise and memory-wise) to define the elements in a table when invoking the table constructor. Which I think is needed rather than just stating "but it is quicker and shorter to do this"

Also consider using locals in all your code examples in an attempt to promote good coding habits.

[sens]

theoriginalbit, on 29 October 2013 - 10:18 AM, said:

You also don't state why it is better (efficiency-wise and memory-wise) to define the elements in a table when invoking the table constructor. Which I think is needed rather than just stating "but it is quicker and shorter to do this"

I'm relatively new to Lua and may be mistaken about this, but what I've read seems to indicate that the two are completely equivalent:

Programming in Lua, first edition said:

That is, all tables are created equal; constructors only affect their initialization.

http://www.lua.org/pil/3.6.html

[Agoldfish]

It seems like you made this after you told me how to use tables :3. Anyway, nice tutorial, might come in handy sometime.

[H4X0RZ]

Good tutorial, but:

local tbl = {["foo"]="bar"}

-------------------------
--This
print(tbl["foo"])
--Is not the same as
print(tbl.foo)
-------------------------
--To do the second type you have to do it like this
local tbl = {foo = "bar"}
print(tbl.foo)

[MudkipTheEpic]

Freack100, on 29 October 2013 - 05:39 PM, said:

Good tutorial, but:

local tbl = {["foo"]="bar"}

-------------------------
--This
print(tbl["foo"])
--Is not the same as
print(tbl.foo)
-------------------------
--To do the second type you have to do it like this
local tbl = {foo = "bar"}
print(tbl.foo)

Misinformation.

It works either way.

[H4X0RZ]

MudkipTheEpic, on 29 October 2013 - 05:45 PM, said:

Freack100, on 29 October 2013 - 05:39 PM, said:

Good tutorial, but:

local tbl = {["foo"]="bar"}

-------------------------
--This
print(tbl["foo"])
--Is not the same as
print(tbl.foo)
-------------------------
--To do the second type you have to do it like this
local tbl = {foo = "bar"}
print(tbl.foo)

/>

Misinformation.

It works either way.

o.O
Since when?
I never saw it...

Sorry for the missinformation BTW...

[theoriginalbit]

Freack100, on 29 October 2013 - 07:31 PM, said:

o.O
Since when?
I never saw it...

Since always. The dot notation is just syntactical sugar. The only time it doesn't work is in this case

local t = {["some key"] = true}
print(t.some key) --# this doesn't work, just like the next line doesn't work
t = {some key = true} --# they follow the same rule pattern

[theoriginalbit]

theoriginalbit, on 29 October 2013 - 07:40 PM, said:

Freack100, on 29 October 2013 - 07:31 PM, said:

o.O
Since when?
I never saw it...

Since always. The dot notation is just syntactical sugar. The only time it doesn't work is in this case

local t = {["some key"] = true}
print(t.some key) --# this doesn't work, just like the next line doesn't work
t = {some key = true} --# they follow the same rule pattern

What you're thinking is that THESE aren't the same

local var = "hello"
local t = {}
t[var] = true --# adds true under the key "hello"
print(t.var) --# looks for a key "var"

which they are not the same.

[Symmetryc]

You can actually use almost any value as a key in a table, not just strings and numbers, so this will work:

myTable[{}] = 5
myTable[true] = 10

[theoriginalbit]

Symmetryc, on 29 October 2013 - 08:11 PM, said:

You can actually use almost any value as a key in a table, not just strings and numbers, so this will work:

myTable[{}] = 5

Of course hoping that you save the table so that you can access it later!

local k = {}
local t = {[k] = "tables as keys!"}
print(t[k])

[Symmetryc]

theoriginalbit, on 29 October 2013 - 08:15 PM, said:

Symmetryc, on 29 October 2013 - 08:11 PM, said:

You can actually use almost any value as a key in a table, not just strings and numbers, so this will work:

myTable[{}] = 5

Of course hoping that you save the table so that you can access it later!

local k = {}
local t = {[k] = "tables as keys!"}
print(t[k])

Well, it depends. Let's say you wanted to just make a table of information that your going to return (you're doing this in a function), the end user will use pairs/next to get the values, so there is really no functional purpose in saving them, although it does add to the readability (*wink* *wink*).

[MudkipTheEpic]

Freack100, on 29 October 2013 - 07:31 PM, said:

-snip-
Sorry for the misinformation BTW...

It's OK, everyone makes mistakes.

[Zudo]

Symmetryc, on 29 October 2013 - 08:11 PM, said:

You can actually use almost any value as a key in a table, not just strings and numbers, so this will work:

myTable[{}] = 5
myTable[true] = 10

I put that in the first part.

[Symmetryc]

ZudoHackz, on 30 October 2013 - 02:13 AM, said:

Symmetryc, on 29 October 2013 - 08:11 PM, said:

You can actually use almost any value as a key in a table, not just strings and numbers, so this will work:

myTable[{}] = 5
myTable[true] = 10

Anyway, it is really stupid to use boolean and tables as well.

I hope you were kidding.

[LBPHacker]

ZudoHackz, on 30 October 2013 - 02:13 AM, said:

I put that in the first part. Anyway, it is really stupid to use boolean and tables as well.

Man, that hurt... That was like saying it's stupid to use C++. You can't just go over and state that a bunch of people is stupid, just because they do things you don't.

[Zudo]

LBPHacker, on 31 October 2013 - 12:46 AM, said:

ZudoHackz, on 30 October 2013 - 02:13 AM, said:

I put that in the first part. Anyway, it is really stupid to use boolean and tables as well.

Man, that hurt... That was like saying it's stupid to use C++. You can't just go over and state that a bunch of people is stupid, just because they do things you don't.

I'm not saying that people are stupid, I was just saying that using boolean and tables is a bad idea, unless there is actually a good reason for doing it.

[Engineer]

You should also explain what happens when you do the following:

local t = {
  x = "random",
  s = "key"
}

local x = t

A hint what you should explain is actually this "strange" behaviour:

x.lol = ":D/>"
print( t.lol )

If you dont understand whats going on there, why have you written this tutorial? 0.o

[Kingdaro]

What Engineer demonstrated has actually screwed me up quite a bit when I was developing with LÖVE a while ago, so it'd be good for OP to explain that.

[ChemE]

Nice tutorial thanks!