is it possible to call subclass's overwrited function in baseclass's init function

bowerandy

@atilim, sorry, me again ]

Forget adding the class name to Core.class(). If you add the RootObject class as the root of all classes as I suggested above (call it Object if you like) then class name retrieval can be added by anyone who requires it:

function Object:getClassName() local class=self.class if class.__name then return class.__name end for k,v in pairs(_G) do if v==class then class.__name=k return k end end end

best regards

atilim

:-h Totally agree about adding an Object class. As you've said, all class related functions can be implemented there.

Also we don't have to find an uncommon name for that root class. If somebody redefines a global variable with name Object like:

Object = 1 -- or Object = {} -- or Object = Core.class() -- or Object = Core.class(Sprite)

he/she only looses the reference to the original Object and that's all. This doesn't break the execution.

bowerandy

@atilim, excellent.

So will you add class Object for the next version and make EventDispatcher descend from it? We can leave out all the fancy stuff (like getClassName(), isKindOf() etc) as that can easily be implemented separately. May I humbly suggest:

Core = {}   Core.class = function (b, optName) local c = {} c.__index = c setmetatable(c, b)   c.super = b c.class=c local __new   if b == nil then __new = function(...) local s1 = {}   setmetatable(s1, c)   local init = rawget(c, "init") if type(init) == "function" then init(s1, ...) end   return s1 end else __new = function(...) local b = getmetatable(c)   local s1 = (b.__new or b.new)(...)   setmetatable(s1, c)   local init = rawget(c, "init") if type(init) == "function" then init(s1, ...) end   return s1 end end   c.__new = __new   c.new = function(...) local s1 = __new(...)   local postInit = s1["postInit"] if type(postInit) == "function" then postInit(s1, ...) end   return s1 end   return c end   Object=Core.class()

If this will go into the next version then I'll probably start using it right away by including the above in my "init.lua".

best regards

john26

Going back to Alex's original point, why not use a "no magic" approach like this

function newBase() local base={} base.say=function(what) print("say from Base",what) end   return base end   function newChild() local child=newBase() -- inherit from base child.hello=function() print("hello from Child") end -- add extra stuff child.say=function(what) print("say from Child",what) end -- polymorphism   --init code child.say("blablabla")   return child end   local child=newChild() -- say from Child blablabla child:hello() -- hello from Child

This does everything we want, is completely explicit and we can change the behaviour if we need to. No metamethods are involved! Any reason not to do OO this way?

ar2rsawseen

@john26 this way you can't inherit for example from Sprite, EventDispatcher or other Gideros related classes.

john26

Couldn't I do something like this

function newChild() local child=Sprite.new() child.name="fred" child.addEventListener=function(self,func,data) ... end   return child end   child=newChild() child:setPosition(10,200) :

OZApps

@John, while your sample is correct, @ar2rsawseen was referring to inheritence from a class, what happens with the code sample you have is simple instantiating an object of the base standard class. So if you had a sprite class that had the function animate, then when you inherited sprA from mySprite, it would be of type sprite and also have the function animate, but when we use Sprite.new() we are not inheriting from it. Not sure if this is a good explanation.

john26

Good point, but does this make a practical difference? In general, I think the "no magic" or DIY approach might be better as you know exactly what is going on. SmallTalk enthusiasts can code their OO system their way and C++ devotees can use that style of OO. Basically, Lua is powerful enough to support any type of OO (and functional programming etc) so personally I think its better to leave this to the user.

bowerandy

@john26, one of the things disliked about Corona was that there was no standard OOP mechanism so everyone invented (or imported) their own. This meant that sharing code OOP code could be difficult so most of the time "plain" non-OOP code was used instead (this may have changed since the last time I looked, though).

If you like to use OOP then the fact that Gideros has a built-in framework is, IMO, a big boon. The Gideros class system is small, intelligible and efficient. Heck, the whole thing is only 58 lines long so there can't be that much "magic" going on. The only thing needed to make rather more useable is the addition of the 5 or so lines discussed in this thread and these are fully backwards compatible with what we have already.

best regards

john26

Yes, I can see it's useful to have a standard. I didn't realise Gideros's OOP framework was written in Lua and so short as well! I definitely think the above Core.class file should be read by everyone attempting to use the built-in OOP system as it will help to understand corner cases (much harder to explain in words). It also means we don't have to wait for a new version to implement this Core.class file ourselves. Perhaps this could be put somewhere accessible?

BTW, where is the core.lua file actually stored? Or is it converted to machine code somehow?

I guess what I mean by "magic" is stuff buried in C++ which we cannot see and so have to memorize lots of obscure rules. Having OO system in a lua file makes it much more transparent.