Lua Generic for

[Karn]

Hello everyone, I'm new in the community, Love2D and Lua (and programming), and as the title suggests, I have a question related to Lua's generic for. I'm having trouble "visualizing" it's aplication, I would like to help to put this subject into context, like, under what circumcstance will this be of use to me in game dev.

Cheers from Portugal.

Programming in Lua page > http://www.lua.org/pil/4.3.5.html

[Jasoco]

Every circumstance.

Pretty much every one. It will be used all the time.

[Taehl]

Generic for/pairs is used for iterating through any table which doesn't have sequential, integer keys (that is, the kind of table you'd use ipairs with). The place I think I've used it most is for handling game content (I put my content in tables, for cleanliness / iterating / etc.), but I've also used it for saving/loading data, combining/copying tables (example: The gene-merging function in my plant game), and component-oriented programming.

[kikito]

I'm not sure about what you are asking. It could be two things.

Are you asking "Why should I use a generic for instead of a numeric for?" or are you asking "Why should I use a for?".

[Nixola]

Can I ask "Why should I use a generic for instead of a numeric one" and "How does generic for work"? I didn't read that part of your tutorial 'cause numbers don't confuse me and I'm fine with numeric ones, so I don't understand how do they work... (I tried to read it later but I don't understand it even after readin' it)

[Karn]

@kikito The question is actually "Why should I use the generic for?"

As I read the Lua book I'm writting it onto Love just to see it in action, like simple operations, etc etc, and now control structures, but I have not yet done anything complex so I'm not seeing the "big picture", I have compiled the example given in the book, it works fine but I didn't really understood its use based solely on that page.
Thanks for your responses so far.

[kikito]

Ok.

Let me begin by saying that you almost never will need ipairs. Numeric fors are just more efficient.

If all tables where like this one:

Code: Select all

letters = { "a", "b", "c", "d" }

... then you would only need numeric fors.

The problem is that not all tables are like letters. In fact lots of them are not.

• Tables indexed by numbers but with "holes" in them
• Tables indexed with negative numbers, or 0
• Tables indexed with non-nombers

Here's an example of the first type. Believe it or not, it doesn't print anything.

Code: Select all

tableWithHoles = {}
tableWithHoles[1000] = "I'm in the 1000th position"
for i=1,#tableWithHoles do
  print(i, "=>", tableWithHoles[i])
end

The reason why it doesn't print anything is because #tableWithHoles is considered 0. Lua has no (predefined) way of calculating the length of a table with holes in it. With a generic for and pairs, you would have got only one line: 1000 => I'm in the 1000th position.

And of course, there is the case in which tables are not indexed by integers at all. For example, they can have strings as keys:

Code: Select all

person = { name = "peter", age = 21, job = "code monkey", likes = "cheetos & montain dew" }

Generic fors are the only ones that will allow you to print them:

Code: Select all

for k,v in pairs(person) do
  print(k, " => ", value)
end

Going back to the begining: I said you almost never need ipairs. I can imagine one case in which it makes sense that it exists; when creating libraries that use iterators as a parameters to functions. But that's not something regular people need (I have done plenty of stuff with Lua and still have not needed it).

Regards!

[Nixola]

Thank you, you just told me that, if I want to solve an annoying bug from my game (if you shoot for more than 5 seconds on a netbook it will start to get slower), I've to use something that I hate...
Since I still don't understand it, I think I'll wait before solving that bug

[kikito]

Have you tried uploading your game here? People are very helpful (I'd recommend replacing/removing long songs to make it small)

[Karn]

Thank you very much for the explanation Kikito, It is all much clearer now.