Re: Love Object Orientated Programming
Posted: Wed Sep 01, 2010 10:33 pm
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.
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
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 wrote: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?
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.vrld wrote: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.
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.leiradel wrote:That can't be a bad thing, can it?
Not really. Each library has its own API anyway, OOP notation is just a minor part of it.leiradel wrote: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.
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.Robin wrote:You seem to know it very well, you should also know that agreeing on a single OOP method is not going to happen.
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.Robin wrote:Not really. Each library has its own API anyway, OOP notation is just a minor part of it.leiradel wrote:Having only one class library improves code readability, interoperability between different libraries and efficiency when writing code.
Well...leiradel wrote:But since we're in a closed system here, *we* could have the benefits of standardization.
I know you are, and that is exactly what I'm arguing against.leiradel wrote: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.
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.Robin wrote:I'd say love.oop would qualify as a kitchen sink.
Hahaha, I couldn't help it could I?Robin wrote:I know you are, and that is exactly what I'm arguing against.