hi SegaBoy,
i checked out the link from reddit. unfortunately, the posted URLs to the original OO tutorials no longer work. however, based on what ErikTboneJackson mentioned, Omid’s original implementation seemed pretty messy and fragile. what Omid has now is better, but seems like a pretty standard method of OO in Lua – it’s really basic. that last point is what i find when looking at most of the more recent implementations/tutorials – they all get the basics down, but don’t tend to move much past that.
the implementation in dmc_objects came from reading many of the same OO articles on the main Lua website (et al) that everyone eventually finds. i saw that they all share the common thread (using the metatable) and that the differences are fairly minimal (eg, what to use as method names, minor features, etc). so i chose elements from each solution that i liked to create what i have. i didn’t change a lot because i don’t believe in re-inventing the wheel if someone has already figured it out for me 
plus, at the time, Corona/Lua were new to me so my Lua OO was weak ; a Jedi i was not.
**my** specific OO implementation differs in that i did add other features beyond the basic OO stuff – some of them geared towards Corona development itself. for example, by default i use a Corona display group to back the Lua object which automatically gives 1. a visual tie into the display hierarchy as well as 2. the ability to dispatch events from the object. i also tweaked table/object property lookup so that i could have the capability of using getters/setters. i think that these features are important for a robust, full-fledged OO solution in Corona and, as much as possible, allow you to use the objects as as you would any native Corona object.
as far as your question about bloated-ness
i wouldn’t worry about it too much for several reasons.
-
the way OO works in Lua (and Javascript for that matter) require you to create objects to form the hierarchy, so it’s already less efficient. that’s just the nature of the solution which the language gives us.
-
as you mentioned, typically you only have a handful of properties on each object so memory requirements are really low. plus we’re only talking about 3 objects (for example) to form a hierarchy, but those 3 objects might serve as templates (parent classes) for 10-100s of objects. to me that’s a pretty good ROI.
-
having those properties on the parent objects allows a hierarchical lookup to succeed. for instance, maybe you have a default class velocity, or number of lives, etc. if you remove (nil) a property on a object, the lookup will go up the hierarchy searching for it. that is what OO is all about, right ?
that said, i should mention that i **have** recently made a modification in dmc_objects, for reasons related to your question, which separates out different stages of object creation. this update allows me to determine the difference between 1. the objects which you actually are using in the app as opposed to 2. those which are created for the hierarchy, then tweak the initializations for each. however, i personally decided to keep property creation on objects because of #3 above. the driver behind the change was more about the visual elements, not object properties.
finally, using __newindex would be a very deep, complex solution to what i think is a minor issue (as i have stated). i used __newindex and its related posse to power dmc_autostore and dmc_objects,… and let me tell you, you’ll run into deep voodoo while walking down that path.
cheers,
dmc
ps, i appreciate your appreciation.
