Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
is it possible to call subclass's overwrited function in baseclass's init function - Page 2 — Gideros Forum

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

2»

Comments

  • bowerandybowerandy Guru
    edited 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

  • atilimatilim Maintainer
    edited 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.
  • bowerandybowerandy Guru
    edited 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
  • john26john26 Maintainer
    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?
  • @john26 this way you can't inherit for example from Sprite, EventDispatcher or other Gideros related classes.
  • john26john26 Maintainer
    edited 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)
    :
  • @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.

    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    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
  • john26john26 Maintainer
    edited 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.
  • @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
  • john26john26 Maintainer
    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.
Sign In or Register to comment.