[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: RES: RES: idea of vision of blueprint of ROADMAP of Lua core
- From: Jay Carlson <nop@...>
- Date: Sun, 16 Jan 2005 00:42:22 -0500
André de Leiradella 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
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.
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
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.