Love Object Orientated Programming

[Robin]

You won't get the community very exited with projects like this, though. If that is your goal, just write a game. Those things are like catnip to us.

[mager1794]

I will ^_^

and I'll create some reusable classes while im at it. But i do intend to develop a good IDE for Love.

I've done it before http://www.mmowned.com/forums/world-of- ... iptor.html and thats not even the final version. The final version was amazing. I intend to base off of my source for that it should only take a few weeks. Is that something to excite the community about? lol

[Luiji]

It would if the last 5 IDEs didn't die.

[leiradel]

I wrote once or twice to the Lua mailing list asking for OOP support in the language. I understand that metatables can be used to fake the OO paradigm in Lua, but there are some problems with them.

One big problem in my opinion is when you use many Lua libraries developed by others. If each use their own OOP library you end up with different ways to do the same thing, i.e. to instantiate one object from a class in one library you use "obj = Class.new()", to do the same thing with a class from another library you use "obj = Class:Create()"...

As OOP is such an useful feature to have, what people think about having a love.oop library, blessed by Löve developers? What features do you need from such a library? Mine are:

1. Don't look cryptic
2. Allow the calling of inherited methods
3. Allow multiple inheritance
4. Be lightweight, i.e. do not perform tons of work when I call a method, ideally just one table lookup to get the method
5. Have an "instanceof" function just like the Java operator with the same name

It should look similar to this:

Code: Select all

local Image = class()

function Image:new( filename )
...
end

local Sprite = class( Image )

function Sprite:new( filename )
  Image.new( self ) -- inherited method call (constructor in this case)
  ...
end

local hero = Sprite( 'hero.png' ) -- calls new with a newly created instance

Polymorphism comes for free as Lua is dynamically typed. An object can be anything, and if it's not the right type, you'll get an error sooner or later: attempt to call method 'xxx' (a nil value)

Hope this helps mager1794 in his efforts and we end up with an OOP library to rule them all...

Cheers,

Andre

[vrld]

As OOP is such an useful feature to have, what people think about having a love.oop library, blessed by Löve developers? What features do you need from such a library?

As said before, the wiki already features some libraries that do what you want to. There is also a complete chapter devoted to OOP in Programming in Lua.

[leiradel]

As said before, the wiki already features some libraries that do what you want to. There is also a complete chapter devoted to OOP in Programming in Lua.

I'm aware of that. I also own a Programming in Lua book, and I have written class libraries myself, the first one being for Lua 3. What I'm saying is that LÖVE should have one and only one class library, and the only way of having that is if the developers embed one inside the engine so it becomes *the* class library. It could be one of the existing libraries or could be a new one.

Imagine yourself using a couple of libraries in your LÖVE application, each one using its own class library. When creating an instance you'll have to remember from which library it is so that you know you have to create it with Class:new() instead of Class.Create(). Having only one class library improves code readability, interoperability between different libraries and efficiency when writing code.

That can't be a bad thing, can it?

[Robin]

That can't be a bad thing, can it?

Except it's Lua. You seem to know it very well, you should also know that agreeing on a single OOP method is not going to happen.

Imagine yourself using a couple of libraries in your LÖVE application, each one using its own class library. When creating an instance you'll have to remember from which library it is so that you know you have to create it with Class:new() instead of Class.Create(). Having only one class library improves code readability, interoperability between different libraries and efficiency when writing code.

Not really. Each library has its own API anyway, OOP notation is just a minor part of it.

[leiradel]

You seem to know it very well, you should also know that agreeing on a single OOP method is not going to happen.

Correct, because Lua authors neither implement it in the language nor mandate that a single class system to be used. But since we're in a closed system here, *we* could have the benefits of standardization.

Having only one class library improves code readability, interoperability between different libraries and efficiency when writing code.

Not really. Each library has its own API anyway, OOP notation is just a minor part of it.

OOP helps with the understanding of the API. Instead of tenths of functions operating in a number of data types you have a number of data types encapsulating their own methods. So while OOP doesn't replace good API design it helps by structuring your program around your data types and not code. Code is something we write with the only purpose of manipulating data.

I'm neither discussing the benefits of OOP nor saying everyone should use it. Only that there should be only one class system for those who want to use it.

[Robin]

But since we're in a closed system here, *we* could have the benefits of standardization.

Well...

The whole issue for Lua is a philosophical decision, LÖVE's philosophy is largely based upon it.

Also, on a more practical note: early in the history of LÖVE, it was going to have everything but the kitchen sink, from which the devs departed later on because it was not practical. I'd say love.oop would qualify as a kitchen sink.

I'm neither discussing the benefits of OOP nor saying everyone should use it. Only that there should be only one class system for those who want to use it.

I know you are, and that is exactly what I'm arguing against.

[leiradel]

I'd say love.oop would qualify as a kitchen sink.

Which is unfortunate. I have this feeling that Lua adoption is held back because many of the available libraries use some kind of class system which is not compatible with other class systems so it's difficult for someone to reuse that code by e.g. extending the base classes to add functionality. You're limit on just using that code.

I know you are, and that is exactly what I'm arguing against.

Hahaha, I couldn't help it could I?

Yeah, I like the OOP paradigm, so much that I've been always looking for a OO scripting language since the limitations of the no-man's-land Lua approach to it came to me. Unfortunately I still didn't find one having all benefits of Lua *and* OO.