Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
Any lua experts - creating instance of class from variable — Gideros Forum

Any lua experts - creating instance of class from variable

moopfmoopf Guru
edited February 2012 in General questions
OK, that's not a great title for this thread but here goes. I'd like to be able to dynamically call a class. So, let's say I have class1, class2, class3 etc. all setup using the gideros.class(Sprite) method.

But, I want to create instances of those classes dynamically, e.g. using "class" and appending the number to the end depending on which one I need at any given time.

I've only been using Lua for a few weeks and I'm wondering if there is any way within it for creating an instance of a class by referencing the class name as a string which I'd concatenate to correspond to the actual class I want.

That still probably makes no sense, but any help appreciated (if you understand any of that).


  • ar2rsawseenar2rsawseen Maintainer
    edited February 2012
    well, as I understand, it's similar to situation, when you have function name in string variable, and you want to call this function.

    Well easiest solution, I can come frop the top of my head, to do something like this:
    --variable to store class name
    local myClass = "class"
    --define your classes
    local myClasses = {}
    myClasses.class1 = class1
    myClasses.class2 = class2
    myClasses.class3 = class3
    -- and the use like this:
    Didn't test it, but should work. Just to show you the idea
  • Yeah, that works, thanks.

    Is there much overhead to doing this? By that, I mean memory usage by putting the classes in a local table? To be honest, this is the part about Lua that I'm finding the most difficult to fully get to grips with (after years of C, C++, Objective-C etc.) as everything seems so loose which is great, and liberating, but also feels wrong on so many levels!
  • Yay, I was faster than atilim and my suggestion worked :D

    ar2rsawseen: 1
    atilim: 619

    Almost got him. Unless atilim has better suggestion :)

    Well I don't think there's much overhead, because myClasses would only store reference to your class, not it's copy.

    But I can understand you, I'm a fan of loosely typed languages, and all of my friends and colleagues are quite opposite. So we usually have discussions, and mostly result is, that I can create more, by writting less, but they can optimizing things on levels, which I can't.

    Both have their good and bad sides, and you can't live only in one world
    +1 -1 (+3 / -0 )Share on Facebook
  • moopfmoopf Guru
    edited February 2012
    Right yes, that makes sense (it being a reference only).

    Whilst I've done a lot of dev work in PHP over the years (and I mean a lot!) and that's loosely typed, it is fundamentally structured not too dissimilar to C in a lot of respects. The whole tenet of Lua seems to be different from languages that use the organisation and basic structure of something akin to C and that, I think, is where I'm finding the most difficulty transferring to Lua.

    It's actually really clever, but after years of using languages that are all constructed around the same basic organisation, Lua is a bit like learning coding again because it's so fundamentally setup in a different way.
  • I felt the same when switched from PHP to Javascript (which is a lot like lua). But now with more than a year in Javascript world, this dynamic object concept seems quite handy and usually missed in other environments.

    Although php, kind of going that way, by supporting closures etc, it's class structures are still "hardcoded" and cannot be so easily changed on runtime.

    Besides that, I also had a week with Objective-C, and although I could dive in and make a game prototype, I'd really prefer not to go back there. :)
  • Objective-C is incredibly verbose. I wrote my last game in Objective-C (used the cocos2D framework) and, I'll be honest, just doing simple things took the most ridiculously verbose code. Part of that is Objective-C just being that way, and part of it was made even worse by cocos2D being pretty verbose as well.
  • gorkemgorkem Maintainer
    In our examples, our Lua code was about 80% shorter (in terms of SLOC) than the equivalent Obj-C code. And I'm not talking about very small examples, but considerably long examples.
  • I don't think it's Obj-C that's verbose, I think it's Cocoa that's verbose, which I can kind of understand considering that it's designed to do everything possible. I don't think games want even a small subset of what Cocoa intends to do. I think something like Gideros is a perfect solution. It has the simplicity of old skool BASIC but the power of OO programming.
  • @Magnusviri, Objective-C syntax is verbose and, because of that, it's very descriptive, e.g:
    [myclass setMyColourRed:255 Green:255 Blue:255];
    Any way you look at it, that's verbose (but also descriptive!) :D
  • Oh, multi-argument function had also pretty interesting concept in Objective-C.

    But most verbose thing I find in strong typed languages, is actually a data type, example from Java

    MySuperAwesomeClass myInstance = new MySuperAwesomeClass()

    It's not descriptive, when you get it twice - it's annoying.
  • But if your API didn't use the descriptive nature of Obj-C you could write that as

    [a setColor:255 :255 :255];

    I had a friend who would code like this. So yeah, I see what you mean about Obj-C encouraging verbosity, but it isn't required and it has more to do with the API and especially Apple telling everyone to quit abbreviating and things like that, which is something I also believe and so my variable names are usually huge.

    But at the same time, I keep thinking that something should be easy to do in Cocoa and an hour later I'm wondering why I haven't got anything to show yet. I haven't written anything serious for Gideros yet but I can see that the Gideros examples that I've run would take a ton of code in Cocoa.
Sign In or Register to comment.