Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
Should I put everything in a table? — Gideros Forum

Should I put everything in a table?

HolonistHolonist Member
edited December 2014 in General questions
Hi all,

First a quick introduction. My first programming language was C++, i learned basically variables, loops and basic console input/output. Then in university I had an extremely dense Java course for half a year, where I learned all the basics about OOP. Since then, I tried my luck with Java, Lua and JavaScript game-development. I am now sticking with Gideros since a few months.

I really like to be in control of everything in my programs. Yet, game development is different from everything I've seen before in coding. There is so much to learn apart from what basic programming concepts look like. There are a LOT of best practices I still have to discover. However, there is this one issue that concerns me since my very first game development attempts. Tutors often create local objects in functions. That always seemed nice and easy, and especially useful if there is a garbage collector in your engine.

But in every project I have the feeling that I lose control at some point in time when I use local objects. Should I create tables for each type of object? Afaik, there is no way to "return" to and target a local object that you released into memory, if it's not in a table. Or is there? Another solution without tables I can think of is attaching sh*tloads of eventlisteners to the object classes.

Just for clarity, an example of what i mean:
//without table
mybutton:addEventListener("click", function()
  local bullet = Bullet.new()
  bullet:doSomethingUntilX()
end)
 
//with table
self.bullets={}
mybutton:addEventListener("click", function()
  table.insert(self.bullets, Bullet.new())
  self.bullets[#self.bullets]:doSomethingUntilX()
 
  //additional magic for removing the bullet when it "dies"
end)
 
</pre
 
Maybe you can tell me what you use as a best practice?
Thanks in advance!

Comments

  • ar2rsawseenar2rsawseen Maintainer
    Accepted Answer
    @Holonist theoretically in Lua everything is in table. Even global variables are in _G table, you can iterate through it and check.
    There is also a way to get variables through local tables (kind of reflection like), but it is usually not needed and might not be as efficient. Mostly used for debugging purposes:
    http://docs.giderosmobile.com/reference/lua/debug#debug

    So as you said yourself, having locals you leave it to grabage collectors to deal with.
    But maintaining it yourself, you also need to free it yourself (to let the same garbage collector to deal with it underneath)

    In both cases garbage collector is involved, so there is no point of managing it yourself, unless, you need to use it in other scope and specifically keep reference a little longer then when scope exits.

    Nothing more then that. :)

    In most cases when I need to keep reference longer, I store them ass OOP properties of Gideros class instance, so they get collected together with the Gideros class instance

    Likes: Holonist

    +1 -1 (+1 / -0 )Share on Facebook
  • john26john26 Maintainer
    edited December 2014
    If you want to be able to return to an object and reuse it, you should make it a global variable. In your second example that is what you are doing since self.bullets is a variable that is outside of the scope of the function. But self presumably maps to a global variable anyway. And, of course, you will probably want to use global tables such as self.bullets.

    I don't see any difference between Lua, Java and C++ in this regard. Of course local variables will disappear when they go out of scope so you need to store them globally if you want them to persist.

    Remember that Lua objects are reference type (like Java) so a table is just a memory location. If you print a table it just prints a memory location.

    Personally I would not put the body of the function in an addEventListener command. I would rather create a global function and then just give the name of that. Makes it easier to read and saves potential confusion.
Sign In or Register to comment.