And as a personal taste, I don't prefer attaching callback functions to table fields by using __index and __newindex. Mainly because it's really easy to forget (and hard to maintain) the connections between fields and callback functions when there are many.
I find this kind of approach easier to understand and maintain:
function Game:updateHealth(health)
self.health = health
-- update UI-- check < 0, if so dispatchEvent(Event.new("gameOver"))-- do other thingsend
@Atilim, that article is for a framework that does not work with OO. In fact the proxy object is a little flawed, I had a little more elaborate proxy object (and of course no listeners) for the compatibility layer between Gideros and that framework.
It is painful to support every property that can be set using the assignment, in Gideros, it may take a little bit of orientation, but then nearly all the API functions are function and not assignment operators.
In the sense
myImage.x =10
and
myImage:setX(10)
and then .isVisible vs :getVisible, .alpha vs getAlpha() that was made to abstract away the setters and getters. Good in the short term, but problematic in the long run for *serious* developers.
Comments
For replication, 99% of the code is Lua code so will work as is.
As for bettering it, in what way would you want to make this better?
Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
Cool Vizify Profile at https://www.vizify.com/oz-apps
I find this kind of approach easier to understand and maintain:
It is painful to support every property that can be set using the assignment, in Gideros, it may take a little bit of orientation, but then nearly all the API functions are function and not assignment operators.
In the sense
Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
Cool Vizify Profile at https://www.vizify.com/oz-apps