How to use OOP?

Hello everyone,

I saw some threads about APIs (for example GUI APIs) with functions like this:

b1 = GuiAPI.newButton(some parmeters)

b1:addFunction(some parameters)

I know that a function which is called with a collon uses the self param, but how does all of this work and how can I code it?

EDIT:
I don't mean the self param, I mean the whole OOP thing

Check out Bubba's video thread and this OOP in Lua Thread

Technically it's not true OOP.
The whole semicolon thing applies to any table that has functions. By calling a function in a table with a colon it automatically passes the table as the first parameter to the function.
For everything else, you need to learn about metatables.
I recommend reading about them here: http://wiki.roblox.com/index.php/Metatable
The robox wiki is by far a better resource for Lua than the CC wiki or the main docs.

Pharap, on 18 May 2013 - 08:39 PM said:

Technically it's not true OOP.

Yep, I'd even go as far to say it's not OOP at all, as it doesn't really fulfill any of the OOP concepts.

The fact that Lua allows one to write…

person.getName(person)

… as …

person:getName()

… is called "Syntactic Sugar".
It's still just a table lookup for the function getName and providing it with the table reference.
You can make it "feel" like OOP, because e.g. in Java you can call methods on objects that looks the same ( person.getName() ).
But the Java-Object person and the Lua-Table person are fundamentally different.

That's like saying a picture of a car and an actual car are vehicles, just because they have one thing in common, i.e. that they look like a car.
But the picture of a car is not a vehicle, it's a picture of one. It can't drive around.

That's the same problem that arises with the Lua-OSes and real OSes.
An OS is not defined by how it looks, but by what it does.
I.e. a LuaOS is at best a simile of an actual OS.

Espen, on 19 May 2013 - 05:48 AM said:

Pharap, on 18 May 2013 - 08:39 PM said:

Technically it's not true OOP.

Yep, I'd even go as far to say it's not OOP at all, as it doesn't really fulfill any of the OOP concepts.

The fact that Lua allows one to write…

person.getName(person)

… as …

person:getName()

… is called "Syntactic Sugar".
It's still just a table lookup for the function getName and providing it with the table reference.
You can make it "feel" like OOP, because e.g. in Java you can call methods on objects that looks the same ( person.getName() ).
But the Java-Object person and the Lua-Table person are fundamentally different.

That's like saying a picture of a car and an actual car are vehicles, just because they have one thing in common, i.e. that they look like a car.
But the picture of a car is not a vehicle, it's a picture of one. It can't drive around.

That's the same problem that arises with the Lua-OSes and real OSes.
An OS is not defined by how it looks, but by what it does.
I.e. a LuaOS is at best a simile of an actual OS.

You could actually write an OS in Lua providing you have a compiler that can compile Lua to native machine code.
Lua OOP can do information hiding and technically is encapsulation.
It can also implement inheritance and overriding, but it's not as strict.
A lot of the OO strictness of languages like Java actually comes from the compilation side of things. Java bytecode instructions are defined to work on 'classes', thus they are in flux depending on what kind of class you create. This means that for the most part you could pretty much compile Lua to Java bytecode and Java to Lua bytecode, you would just have to make the compilers limit certain aspects (I'm fairly certain access such as private and final are compiler implemented and you could ignore them if you wrote pure Java bytecode).

Pharap, on 19 May 2013 - 09:00 AM said:

Lua OOP can do information hiding and technically is encapsulation.
It can also implement inheritance and overriding, but it's not as strict.
A lot of the OO strictness of languages like Java actually comes from the compilation side of things. Java bytecode instructions are defined to work on 'classes', thus they are in flux depending on what kind of class you create. This means that for the most part you could pretty much compile Lua to Java bytecode and Java to Lua bytecode, you would just have to make the compilers limit certain aspects (I'm fairly certain access such as private and final are compiler implemented and you could ignore them if you wrote pure Java bytecode).

True that. But as you said, there are quite a few things that'd have to be established before you can use it as such.
I don't fully agree that the strictness of Java is just due to the compilation side of things, as you have said. Java was created with just such strictness in mind (regarding the OOP aspect with its classes, etc.) as its OOP orientation was one of its design-concepts.
As it is right now, Lua isn't an OOP language per design and you have to do hacky tricks to simulate OOP with it.

Pharap, on 19 May 2013 - 09:00 AM said:

You could actually write an OS in Lua providing you have a compiler that can compile Lua to native machine code.

I wholeheartedly agree. You can actually do that - in principle - with any programming language, provided you have a compiler that can compile it to native machine code.
But there's the rub, though. Provided you have a compiler that can actually do that. ^_^/>
Mind you though that I'm specifically talking about programming languages that weren't designed for low level processing.
Since anything is possible in principle (to a degree), I'm generally talking about programming languages the way they were made or intended.

I admit that it might sound a bit defensive, so let me just add that - in the case of Lua - I'm actually aware that there's an attempt at a Lua OS. (I hope this doesn't encourage the wrong people :wacko:/>)
So yeah, stuff like that is always possible in principle.

Espen, on 19 May 2013 - 06:58 PM said:

* Snip *

I'm actually aware that there's an attempt at a Lua OS. (I hope this doesn't encourage the wrong people :wacko:/>)
So yeah, stuff like that is always possible in principle.

That guy seems to be seriously disturbed… :P/> (really, check his videos)

Orwell, on 19 May 2013 - 09:24 PM said:

That guy seems to be seriously disturbed… :P/> (really, check his videos)

Methinks you may be right about that… Apparently spiritual influences are the cause of poor computer performance. Who knew?
Also, there is a love revolution, in case anybody missed out on that memo.

As to Lua not having true OOP, could you please provide a bit more of a substantial reasoning behind that? You have a good metaphor, but I'm not really so certain that it applies.

If we assume that the definition of OOP is a style of programming which allows for objects to be represented as a field of (usually default) values and methods, then I would argue that in fact Lua is, at least somewhat, OOP oriented. Lua does not execute OOP in the same way that Java does, but execution is just that - preference.

Now of course, I am not suggesting that Lua is fully an Object Oriented language. It doesn't support everything that Java does, even in the context of OOP. But nonetheless, the basic capability is still there.

Rereading the posts and reflecting on what the essence of both arguments is, I've come to the conclusion that what I'm trying to say can be summed up as this:
Lua isn't OOP, but you can do OOP with it nonetheless.

I was trying to say the former, but didn't make quite clear that I wasn't also arguing against the latter.
Basically I try to distinguish bewteen the intent or, perhaps better, design of the language and its capabilities.
The latter does not dictate the former.

Exaggerated example for clarification:
You can create artful pictures with Lua by printing out code on pages in certain patterns, etc.
That doesn't mean Lua is an art language, just that you can use it as such.
I.e. art wasn't one of its core design principles, it isn't an art language by definition.


TL;DR:
is (in the sense of made for/most useful for/per design) vs. can

It makes sense that Lua isn't designed for Object Orientation if you actually read it's history.
Besides, in my opinion Java is too object orientated.
I think a mix of paradigms or being able to choose a paradigm always yields the best results,
like with C++ and C# where you can do things like function pointers and lambda expressions with ease.

At any rate I think this debate has gone on long enough and diverted from the actual purpose of this thread.

Check this, in my opinion is the best tutorial: http://www.computercraft.info/forums2/index.php?/topic/12518-a-nice-small-class-implementation/