lua-users home
lua-l archive

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

>* Oberon-2 and Component Pascal both insist that one name the receiver and
>use that name throughout the method. On the other hand, you can use a one
>letter name and I also can't point to Oberon-2 and Component Pascal as
>wildly successful.

I agree, and I'm going to use "@" as the receiver name always ;-)

>* I can see the issues with inheritance but I've also been weaning myself
>from using inheritance.

Unfortunately I'm trying to write a GUI entierly in Lua, besides the drawing
primitives, and it's very difficult to do so without inheritance.

>* My biggest problem using Lua for object-oriented style programming has
>been typing "." instead of ":" when invoking a function. I understand why
>"." can't just do the job -- sometimes you do just want a table entry
>containing a function pointer. I've been contemplating adding a syntactic
>option that would allow me to write:

The "@" trick does help here, it decides weather to use "." or ":" based on
the first non space character after the identifier that follows "@". If it's
a "(", use ":" else use ".".

>    myObject << message(...)

Well, I could add an option to my class pre-processor that would change "<<"
into ":", so "myObject << message(...)" changes to "myObject:message(...)"
which does what you want. Handling nil objects is harder though because the
pre-processor would have to keep track of all identifiers in the stream so
that when a "<<" is found the apropriate code could be generated.

>Or maybe I'll just learn to be more careful about "." v ":".

Or use a class pre-processor to allow you to use "@" if you don't mind about
breaking source code compatibility... It's my case because my GUI will be
used by users not very knowleadgeble about Lua or programming in general, so
I'm trying to make their life easy, and the code they'll write isn't
supposed to be used in other Lua vms (and even that can be possible, just
compile your code first using the pre-processor).

Andre de Leiradella