RES: RES: RES: idea of vision of blueprint of ROADMAP of Lua core

[André de Leiradella <leiradella@...>]

First of all I'd like to apologize to everyone in the list for being
such an idiot, defending the inclusion of OOP in Lua's core and the
exclusion of the packaging system *from* the Lua's core (though I
already know that it's being implemented as an add-on). I guess it's
really hard to make everyone happy...

> I think you're looking for Io, Lua's OO stepchild.
> http://www.iolanguage.com/
> 

I looked at it some time ago and I liked it, but I think it's too
difficult for users of my applications to learn. I'm looking for
something in the line of objective Pascal or Java.

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

Can I subclass a component to make a new component? I guess so, but
probably in a different manner compared to me own class system.

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

So it's not OOP, just "packaging" functions concerning UI components in
their tables and cloning the tables.

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

It does :) If you take Java, qualification of member access can be done
with a preceeding this if you want...

Regards,

Andre de Leiradella