Re: Implementing "super()" for classes

[spir ☣ <denis.spir@...>]

On Fri, 7 May 2010 16:54:21 -0300
Romulo <romuloab@gmail.com> wrote:

> > "self:super()" would, I assume, return a table with the object's data but with the functions of the superclass.  Could this be accomplished by making a copy of the object table and setting its metatable to the base class table?
> 
> I think that making a copy of the super class is very inefficient and
> error prone. What I usually do is to define an attribute in the
> derived class pointing to the base class:
> 
> --~~--
> 
>    function createClass(base)
>        local newClass = {} -- Contains class methods
>        local classMeta = { __index = newClass }
> 
>        if base
>        then
>            newClass.super = base
>            setmetatable(newClass, { __index = base })
>        end
> 
> --~~--
> 
> And then, in my code:
> 
> --~~--
> Parent = class()
> Child = class( Parent )
> 
> function Child:init( ... )
>   Child.super.init( self, ... )
> end
> --~~--
> 
> Note that when you want to access the super class, you have to index
> the the current class ("Child.super"), instead of "self.super",
> because self's class can be different than the class you declared the
> method.
> 
> --rb

I consider this the best method, because simple, clear and efficient.
But I prefer an OO system where a class holds all methods, meaning createClass copies references to it's base's slots, if any (this is done once). So that there is no method lookup chain (possibly costly & problematic): a slot is either on the instance or on its type.

In the cases where a method needs to call the version of a superclass (this is rare for another reason), it is simply renamed in the subclass:
    SubClass.superDraw = SuperClass.draw
Or, if the subclass's method is often called or the superclass's code is short, it may be better to simply include it in the method body and thus avoid additional method lookup and call.

Denis

PS: Trying to mimic another language's style/logic/features may not be the best idea.
It took me a long time because my brain is rather inefficient, but I finally realised that a majority of coding needs in Lua don't require any formalized OO framework over what the language provides out of the box. Mainly thank to literal notation for individual objects (read: tables) and a few other syntactic/semantic features like ':'.

What I miss is:
* A distinction between tables representing "composite data units" (user objects, flexible records) and tables representing collections. And/or distinct optional __indexitem & __newitem metamethods mirroring this (& thus solving a well-known issue about item vs slot lookup).
* A distinction between sequence and mapping collections, avoiding confusion & traps,  thus allowing standard Lua to complete the set of useful methods for each.
* That table definitions be executable blocks! (Inside its own scope.) So that one can refer to previously defined slots in further ones, or even to the table itself.
________________________________

vit esse estrany ☣

spir.wikidot.com