Is Corona Implementing Its Own Oop Process?

So after finally getting to grips with metatables (thanks largely to dmc), I’ve noticed the following in the latest daily build documentation:

 

 

CoronaClass

CoronaLibrary

object:getCurrentProvider()

object.name

object.publisherId

object.revision

object:setCurrentProvider()

object.version

CoronaPrototype

object:initialize()

object:instanceOf()

object:isClass()

object:isRoot()

object:new()

object:newClass()

object:setExtension()

CoronaProvider

 

There’s a lack of any concrete information in each category, although CoronaClass:new() does have this: 

 

Constructor for creating new object instances. The object is assumed to be a class object.

 

The Library and CoronaProvider API’s appear to be related to perhaps Project Gluon.

 

If Corona is about to unveil an “official” way to do OOP then I’m happy to rip up my implementation and start again; any hints?

 

It will be great if it is an OOP, this will help a lot in getting rid of my spaghetti code and will help manage the unstopping memory leaks! , please CoronaLabs team confirm this?

 

Thanks SegaBoy :slight_smile:

There is a way to do OOP in LUA why do you need new things? all my code screens and all is based on classes… what do you mean by this?

 

EDIT: link to some basis on this: http://lua-users.org/wiki/SimpleLuaClasses

 

Then you sometimes have to envelope some objects from corona in order to do right the callbacks and all, specially for buttons and scrollviews, but once done is easily used in all your projects.

Yeah… Not sure how I’m feeling about this. I’ve been vocal several times on this forum about the need (in my view) for a SERIOUS but clear tutorial on how to do object oriented programming in Lua. Something lacking not only on the Corona site, but on the internet as a whole. Or put otherwise: there is a unique opportunity for CoronaLabs to direct a lot of traffic (at least that’s how I imagine it) to the Corona site, if they would be the only ones offering this content this way.

 

So I should be glad if there is some OOP-stuff coming Corona’s way. But, it worries me a bit that CoronaLabs seems to be taking the route of not doing this the way it is already implemented in Lua, but through some new classes in the API.

 

So like I said, not sure how I feel about this. Probably boils down to speed and ease of use, I guess, so the verdict is still out!

Hi @thomas6,

I remember you mentioning this in a blog post (the need for a solid, tested, flexible OOP methodology in Lua/Corona). I’m curious, have you reviewed Omid Ahourai’s method on his website? I’m curious to hear your thoughts on this.

 

http://www.ardentkid.com/blog/from-zero-to-oo-ardentkids-guide-to-object-oriented-lua-with-corona-sdk

 

Brent

I’ve got my entire game and all classes done in OOP, all my apps use this, in fact I’ve done my own framework that works “with” corona in order to do the tasks, but the games / apps themselves rely on this framework. If later you’ve to change stuff you can just replace it in the framework and you’ll avoid risks in the app / games code.

 

I use that method, and class setup working perfectly with corona + mercurial in order to do a common base for all projects you just update the “framework” in one place and then you’ve got the tools available for all.

 

I guess that comes with experience but from my experience the more code you can externalize into classes and tools the better.

 

Other good point about these type of LUA classes is that you can define them in several files, this is well known, but I point it out because you can do some code generation on external tools and then get it loaded automatically in your app without doing anything special.

 

I gues Omid Ahourais method is  similar to what I mean, but as I said with the simple class structure from LUA website, and a bit of order and code cleanness you can get a very powerful structure to work with.

Hi Brent,

 

I’m very grateful to Omid for sharing his OOP work with the community free of charge (and even taking the time to revise his work based on constructive criticism from readers). Very cool of him. Regarding his implementation of OOP though, I do work in a different way and find some of the code structured in weird ways with him (or better said: in weird places - I understand why the code is there, but I would put some of the code that is in his object-code into the main game logic instead.

 

I’ll share my own code for simple OOP here, code that is basically very useful for a) modularizing your game code, B) spawning easily and most of all c) just creating an object and relying on that object itself to run all of it’s relevant code - no further maintenance or management required. This last point is the biggest advantage of OOP for me, actually.

 


-------------------  
-- bulletClass.lua --  
-------------------

local bulletClass = {}  
local bulletClass\_metatable = { \_\_index = bulletClass} -- metatable

bulletClass.frameLoop = function(self, event)

 -- draw self  
 self.image.x = self.image.x + self.xSpeed  
 self.image.y = self.image.y + self.ySpeed  
   
 -- see if bullet needs to fade and die  
 if event.time - self.startTime \> 1000 then  
  if self.fading == false then  
   self.fading = true  
   transition.to(self.image, {time = 800, xScale = .1, yScale = .1, transition = easing.inQuad})  
   timer.performWithDelay(850, function() self:stop() end)  
  end  
 end   
end -- frameLoop

bulletClass.start = function(self)  
    -- this is our unique anonymous function  
    -- we need to give \*this one\* back to the event listener  
    --  
    local callback = function(event)  
        self.frameLoop(self, event)  
    end  
    self.f = callback  -- let's save the function for later  
   
    Runtime:addEventListener( "enterFrame", callback )      
end -- bulletClass.start

bulletClass.stop = function(self)  
 local callback = self.f  
 Runtime:removeEventListener("enterFrame", callback)  
 self.image:removeSelf()  
 self.image = nil  
 self = nil  
end -- bulletClass.stop

-- CONSTRUCTOR --  
-----------------  
bulletClass.new = function(x,y,xSpeed,ySpeed)  
     
    local bulletInstance = {}  
    bulletInstance.image = display.newImage("ButterflyBullet.png", 200,200)  
 bulletInstance.image.xReference = 36  
    bulletInstance.image.x = x  
    bulletInstance.image.y = y  
    bulletInstance.xSpeed = xSpeed  
    bulletInstance.ySpeed = ySpeed  
    bulletInstance.image.rotation = math.deg(math.atan2(ySpeed, xSpeed))  
    bulletInstance.fading = false  
    bulletInstance.startTime = system.getTimer()

    setmetatable (bulletInstance, bulletClass\_metatable)  
    bulletInstance:start()  
    return bulletInstance  
     
end

--  
--

return bulletClass

 

That’s it. This object takes care of it’s own removal so you don’t even need to give it a handle. Just require “bulletClass” from your main.lua file and then say bulletClass.new(x position to start, y position to start, x speed per frame, y speed per frame)

 

Don’t have the time to go into further detail but suffice to say that this just a simple practical example of basic OOP without inheritance, sub- or superclasses etc… But I do believe that, together with an even simpler static class this cover 99 percent of the OOP needs for Corona programmers.

 

Also I must say THANK YOU to dmCuskey, how was essential in my understanding of this. Thank dmCuskey!

Wow, the new “code” tags really suck. Not only is the white on black text completely illegible (come on Corona guys, do you guys just take random guesses for color schemes or do you actually research this? I’ll give you a hint: any first year typography student knows that this is a no-no), but also so weird paragraph tags are all over the place. Strange.

 

Well, pretty underwhelmed with the new forums so far!

Try the using the lua tag instead of code tag. It should format better  :slight_smile:

Hey CraftyDeano,

 

Thanks for the suggestion - only now one empty line is inserted inbetween every line of code - so I changed it back to “code” tag. Sheesh! If it ain’t broke…

Edit: I see what you mean! 

I followed this http://lua-users.org/wiki/ObjectOrientedProgramming and found it pretty straightforward without doing special stuff… :S why would you use something different?

It may be personal but I find these tutorials to be geared towards “programmers” instead of casual coders - no challenge for me since I’m a programmer, but I see people having issues with this.

 

I fully agree that these tutorials do document the right way to do OOP with Lua, without needing other frameworks on top, but I do feel that these tutorials fall way short of OOP programming specifically geared towards Corona coders (meaning: for use with display objects that have enterFrame and touch listeneners, and need to be able to remove themselves smartly etcetera). As soon as you dive into these topics you notice that in-depth information on OOP and Corona is sorely lacking.

 

Out of curiosity, matrix2000, do you incorporate enterFrame listeners, timers, etc… in your OOP implementation? If so, do you mind posting some code?

Yes, I do, I ussually wrap them up in another function:

 

My objects have a listeners list then when I want to propagate an event I do as following:

 

[lua]

for i, v in pairs(self._listeners) do

 

  event._params = self._params – my own params injected in the event.

  v.listener[v.fun](v.listener, event) – my call to the listener.

end

 

[/lua]

method 1:

For enter frame, I define an “object:enterFrame(event)” method, this one you should call it exactly like this or use method 2

 

Runtime:addEventListener( “enterFrame”, self )

 

method 2

local function callback(event)

            object:callMyRealFunction(event)

end

Runtime:addEventListener( callback )

 

and for timers same thing:

 

 

timer.performWithDelay(700, function()

        object:function(parameters)

    end 

as you see you can wrap them up easily (of course this code applied with care and to your own structure).

 

I hope this helps to everyone.

 

 

 

It will be great if it is an OOP, this will help a lot in getting rid of my spaghetti code and will help manage the unstopping memory leaks! , please CoronaLabs team confirm this?

 

Thanks SegaBoy :slight_smile:

There is a way to do OOP in LUA why do you need new things? all my code screens and all is based on classes… what do you mean by this?

 

EDIT: link to some basis on this: http://lua-users.org/wiki/SimpleLuaClasses

 

Then you sometimes have to envelope some objects from corona in order to do right the callbacks and all, specially for buttons and scrollviews, but once done is easily used in all your projects.

Yeah… Not sure how I’m feeling about this. I’ve been vocal several times on this forum about the need (in my view) for a SERIOUS but clear tutorial on how to do object oriented programming in Lua. Something lacking not only on the Corona site, but on the internet as a whole. Or put otherwise: there is a unique opportunity for CoronaLabs to direct a lot of traffic (at least that’s how I imagine it) to the Corona site, if they would be the only ones offering this content this way.

 

So I should be glad if there is some OOP-stuff coming Corona’s way. But, it worries me a bit that CoronaLabs seems to be taking the route of not doing this the way it is already implemented in Lua, but through some new classes in the API.

 

So like I said, not sure how I feel about this. Probably boils down to speed and ease of use, I guess, so the verdict is still out!

Hi @thomas6,

I remember you mentioning this in a blog post (the need for a solid, tested, flexible OOP methodology in Lua/Corona). I’m curious, have you reviewed Omid Ahourai’s method on his website? I’m curious to hear your thoughts on this.

 

http://www.ardentkid.com/blog/from-zero-to-oo-ardentkids-guide-to-object-oriented-lua-with-corona-sdk

 

Brent

I’ve got my entire game and all classes done in OOP, all my apps use this, in fact I’ve done my own framework that works “with” corona in order to do the tasks, but the games / apps themselves rely on this framework. If later you’ve to change stuff you can just replace it in the framework and you’ll avoid risks in the app / games code.

 

I use that method, and class setup working perfectly with corona + mercurial in order to do a common base for all projects you just update the “framework” in one place and then you’ve got the tools available for all.

 

I guess that comes with experience but from my experience the more code you can externalize into classes and tools the better.

 

Other good point about these type of LUA classes is that you can define them in several files, this is well known, but I point it out because you can do some code generation on external tools and then get it loaded automatically in your app without doing anything special.

 

I gues Omid Ahourais method is  similar to what I mean, but as I said with the simple class structure from LUA website, and a bit of order and code cleanness you can get a very powerful structure to work with.

Hi Brent,

 

I’m very grateful to Omid for sharing his OOP work with the community free of charge (and even taking the time to revise his work based on constructive criticism from readers). Very cool of him. Regarding his implementation of OOP though, I do work in a different way and find some of the code structured in weird ways with him (or better said: in weird places - I understand why the code is there, but I would put some of the code that is in his object-code into the main game logic instead.

 

I’ll share my own code for simple OOP here, code that is basically very useful for a) modularizing your game code, B) spawning easily and most of all c) just creating an object and relying on that object itself to run all of it’s relevant code - no further maintenance or management required. This last point is the biggest advantage of OOP for me, actually.

 


-------------------  
-- bulletClass.lua --  
-------------------

local bulletClass = {}  
local bulletClass\_metatable = { \_\_index = bulletClass} -- metatable

bulletClass.frameLoop = function(self, event)

 -- draw self  
 self.image.x = self.image.x + self.xSpeed  
 self.image.y = self.image.y + self.ySpeed  
   
 -- see if bullet needs to fade and die  
 if event.time - self.startTime \> 1000 then  
  if self.fading == false then  
   self.fading = true  
   transition.to(self.image, {time = 800, xScale = .1, yScale = .1, transition = easing.inQuad})  
   timer.performWithDelay(850, function() self:stop() end)  
  end  
 end   
end -- frameLoop

bulletClass.start = function(self)  
    -- this is our unique anonymous function  
    -- we need to give \*this one\* back to the event listener  
    --  
    local callback = function(event)  
        self.frameLoop(self, event)  
    end  
    self.f = callback  -- let's save the function for later  
   
    Runtime:addEventListener( "enterFrame", callback )      
end -- bulletClass.start

bulletClass.stop = function(self)  
 local callback = self.f  
 Runtime:removeEventListener("enterFrame", callback)  
 self.image:removeSelf()  
 self.image = nil  
 self = nil  
end -- bulletClass.stop

-- CONSTRUCTOR --  
-----------------  
bulletClass.new = function(x,y,xSpeed,ySpeed)  
     
    local bulletInstance = {}  
    bulletInstance.image = display.newImage("ButterflyBullet.png", 200,200)  
 bulletInstance.image.xReference = 36  
    bulletInstance.image.x = x  
    bulletInstance.image.y = y  
    bulletInstance.xSpeed = xSpeed  
    bulletInstance.ySpeed = ySpeed  
    bulletInstance.image.rotation = math.deg(math.atan2(ySpeed, xSpeed))  
    bulletInstance.fading = false  
    bulletInstance.startTime = system.getTimer()

    setmetatable (bulletInstance, bulletClass\_metatable)  
    bulletInstance:start()  
    return bulletInstance  
     
end

--  
--

return bulletClass

 

That’s it. This object takes care of it’s own removal so you don’t even need to give it a handle. Just require “bulletClass” from your main.lua file and then say bulletClass.new(x position to start, y position to start, x speed per frame, y speed per frame)

 

Don’t have the time to go into further detail but suffice to say that this just a simple practical example of basic OOP without inheritance, sub- or superclasses etc… But I do believe that, together with an even simpler static class this cover 99 percent of the OOP needs for Corona programmers.

 

Also I must say THANK YOU to dmCuskey, how was essential in my understanding of this. Thank dmCuskey!