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

bowerandy · January 2013

@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 · January 2013

:-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 · January 2013

@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 · January 2013

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 · January 2013

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

john26 · January 2013

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 · January 2013

@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 · January 2013

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 · January 2013

@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 · January 2013

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.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

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

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

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

Comments