Re: Cryptic OOP syntax

[Mike Pall <mikelu-0501@...>]

Hi,

Andre de Leiradella wrote:
> I love Lua, I want to continue using Lua, but the only reason I'm
> discussing OOP in Lua is the lack of an alternative.

Given the goals you state it is your best alternative. It's much less work
to extend Lua than to downstrip anything else.

> Having a clean workaround would do it, but maybe putting OOP in the core
> won't make it much bigger and maybe Lua would get a broader audience?

Well, first a personal opinion: I do not miss anything in Lua as far as
OOP is concerned. Ok, maybe I'm not an OOP power user then. But anyway,
here is the point I want to make:


I think it's unlikely that the Lua authors want to merge a change into
the core that favours any particular style of OOP (or even OOP in general).
You'll notice that ':' and the automatic 'self' are the only two concession
to OOP. They have a minimal impact on the core. Adding them was not costly.
Lua is all about meta-mechanisms, not about forcing something upon its users.

So here is the magic recipe to eventually get something into the Lua core:

1.  Change your own copy of the Lua core for your favourite OOP style.
    Use it and improve it. Publish your changes.

2a. Live with it, make your patches less intrusive and only update to a
    newer version of the core if there is a good reason. Many people do so.

... OR ...

2b. Think about a minimalistic meta-mechanism in the core that allows one
    to do the kind of extensions you require _outside_ of the core.

3.  Code it up, publish your meta-mechanism and discuss it on the list.
    If your changes are generally useful the Lua authors may consider it
    for inclusion into the core.

In your case you are mainly asking for syntactical sugar. This means
changing the parser and/or the compiler. This is one of the things where
the Lua core lacks a proper meta-mechanism.

Simplistic context-free sugar (such as s/@/self./) can be done by
preprocessing the source with a bit of care (quoted strings et al).
You put a wrapper around the script loader and you are done. No changes
to the core required -- everyone is happy.

But this is not a solution for more complex extensions that need some
context (lexical state, scopes, instruction stream).

Unfortunately it seems very hard to add a proper meta-mechanism to
flexibly extend the parser and the compiler. There has been some discussion
on the list about this, but there is no silver bullet solution on the
horizon. Either you don't get enough access to internal context or you
end up rewriting the whole compiler.


So IMHO instead of discussing everyone's favourite OOP style and what
kind of syntactic sugar is needed to support it, I suggest collecting
and categorizing the needed changes to the core. Then invent a good
meta-mechanism that covers most of these cases (and maybe some more)
and implement it.

Looking at the ways other languages have solved this issue or failed
to do so might be a good idea, too.

[Now crawling back into my cave and working on improving coroutines
 with minimal impact on the core. :-) ]

Bye,
     Mike