lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

André de Leiradella wrote:

lua-bounces@bazar2.conectiva.com.br wrote:


Yes, this (classes) could well get my vote for things to commonalize
(not standardize ;) after the modules dilemma will be out of the way.

Something like a simple 'class.' table like the rest of the Lua
add-ons.  I'd like that. :)

Of course, there's nothing keeping us from starting that work already
now.

-ak



I'd like to see classes implemented in the core as first class values,
not just commonalized or standardize.
I think you're looking for Io, Lua's OO stepchild. http://www.iolanguage.com/ 


Let's suppose someone makes an wonderful GUI extension to Lua based on
his/her class system (does anybody know of a GUI lib that's not object
oriented?). You have your very own class system for your application.
How would you use the GUI ext? Having two different class systems in
your program would probably lead you to many programming errors...
The issue didn't come up in Lua FLTK, since there was no reason to subclass anything from the toolkit. Clients used the . (for VB-style properties) and : syntax. How Lua FLTK implemented its own object system was a private matter.
I think a lot of the interoperability issues you're worried about (like super) only show up when attempting to inherit from or delegate to an existing object system. Most of the commonly-used Lua extensions don't require this, and in the few cases they do, they are simple to use and often accidentally compatible with many different off-the-shelf object systems. The lack of a mandated object system in Lua leads to designs where libraries avoid implementation inheritance as an extension strategy. Some people believe that implementation inheritance is a bad idea anyway.
I've been pleasantly surprised that Lua seems to work well without a mandated object system. My initial fears were that this lack would lead to just the problems you mention.
By the way, I spent about ten years programming in a language that required the "self.foo"/"this.foo" qualification. It feels natural to me. Also, explicit qualification of member access helps make clear to the reader what operations have persistence beyond a single method invocation. Your taste may vary, of course. 

Jay