Re: Implementing "super()" for classes

[steve donovan <steve.j.donovan@...>]

2010/5/8 spir ☣ <denis.spir@gmail.com>:
> 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.

That strikes me as premature optimization ;)  First benchmark, then inline code.

I end up doing a lot of BaseClass.method(self,args) and then I do miss
Java's 'super', One could get this by setting the environments of all
the methods so that it can find the pseudo-object 'super',

> PS: Trying to mimic another language's style/logic/features may not be the best idea.

Ditto! Once the scales fall off the eyes, one no longer sees
everything in the classic OOP model, and one falls in love with
closures...

> What I miss is:
> * A distinction between tables representing "composite data units" (user objects, flexible records) and tables representing collections.

It is not difficult to write wrapper objects which allow disciplined
access to tables-as-collections (for instance the List class in
Penlight).  We still have a way to go, a Map class is problematic
because of the item vs slot lookup problem you mention.

I've also argued previously that relying too much on 'anonymous' types
is a problem for big projects;  it helps if tables acting as 'structs'
have a distinct identity through a unique metatable.

> * 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.

This definitely makes some things easier, but it's a big change. It
complicates the lookup rules, which are fairly simple in Lua.  Try
some big-scale C++ and see your brain using extra cycles trying to
keep track of symbol lookup!

steve d.