LÖVE

A very long Post, but a nice abstract on how OOP works.
I used to design my game objects using tables and functions when I started Learning Lua...Metatables and thus Pseudo-OOP in Lua was quite frightening to me... Then, while I as working on a RTS Game for PSP, I jumped into it...

These abstracts helped me a lot...
Wikipedia
OOPBasics
OOPFundamentals

And the official Lua how-to tutorial...
PIL - OOP

I didn't want to make a huge post similar to that. I understand that tables in tables are just classes and subclasses without properties. Or methods. But, I didn't say what was in those. WeaverOOP uses just tables right now, no metatables. (Don't understand those yet: kind of new to metatables. ROBLOX locked them...) My TTB game so far has a class called "enity" and 2 instances, "character" and "enemy". Those are copies of the orginal to be changed and worked with without messing the class. They have all the properties of the orginal. So, if I want 10, I could use h1 or h2 and so forth=ball:new() 10 times, and have 10 copies of that. Not effective yet, but the basics of OOP are found within that. Thanks for trying to help,

LuaWeaver.

Is it possible to add a callback to an instance of an inherited class? For example:
I ask this because it doesn't seem to be working in my implementation of it.

Your best bet is to redefine initialize in your instance like this:

Middleclass-extras lets you do lots of things: https://github.com/kikito/middleclass-extras

Callbacks is a powerful mixin that allows you to add ‘hooks’ to any existing method. For example, you can specify on runtime that you want to call a method after initializing one object.

Invoker is a very small mixin that can be used to ‘send’ methods to instances. It’s main advantage is that it accepts both method names and lua functions on its parameters.

Not really sure how relevant these are, but they seem like they are what you are asking for.

BlackBulletIV wrote:Your best bet is to redefine initialize in your instance like this:

Code: Select all

function jim:initialize()
  Boy.initialize(self)
  print("Jim also initialized")
end

Thanks, I was hoping that the callback mixin had built in support for that, but I suppose not.

TechnoCat wrote:Middleclass-extras lets you do lots of things: https://github.com/kikito/middleclass-extras

Callbacks is a powerful mixin that allows you to add ‘hooks’ to any existing method. For example, you can specify on runtime that you want to call a method after initializing one object.

Invoker is a very small mixin that can be used to ‘send’ methods to instances. It’s main advantage is that it accepts both method names and lua functions on its parameters.

Not really sure how relevant these are, but they seem like they are what you are asking for.

Yes, I was actually attempting to use callbacks for that, however it doesn't seem to work on instances. BlackBullet's method above works fine, however.

jmazouri wrote:

BlackBulletIV wrote:Your best bet is to redefine initialize in your instance like this:

Code: Select all

function jim:initialize()
  Boy.initialize(self)
  print("Jim also initialized")
end

Thanks, I was hoping that the callback mixin had built in support for that, but I suppose not.

I'm not sure, I haven't used many of the middleclass-extras mixins. But anyway, this method is certainly a bit cheaper performance-wise when compared to using some sort of callback system.

jmazouri wrote:Yes, I was actually attempting to use callbacks for that, however it doesn't seem to work on instances. BlackBullet's method above works fine, however.

The callbacks module is supposed to be used with instances; it's its main use. If you are having trouble with it, then you are either not using it correctly, or you are using other modules that modify the class significantly (for example, Callbacks and Stateful have issues when included simultaneously in a class).

Independently of that, using the Callbacks module makes every call to a method slower; BlackBulletIV's option is the preferred solution to your problem.

Hi everyone, I've released version 2.0 of middleclass.

As always, it is on github: https://github.com/kikito/middleclass

Version 2.0 is a complete re-write of the library. I've done my best to keep the changes as little as possible, but there are some backwards-incompatible changes. Sorry about that.

Here is the changelog:

• Static methods are now separated from instance methods
• class.superclass has now become class.super
• It's now possible to do class.subclasses
• middleclass is now a single file; init.lua has dissapeared
• I've moved the tests back to the project, where they should have been. I've also added some performance tests.
• license is changed from BSD to MIT. License included inside middleclass.lua

The most obvious change is the first one; now there is a way to declare class methods (called static methods). On middleclass 1.x there was no difference between them and instance methods:
Now the recommended way of declaring class methods is using static: Apart from the declaration, the usage is similar. You do instance:myInstanceMethod() and Class:myClassMethod(), just like before.

The advantage of this change is that now you can have a class method and a instance method called the same way. In that case, Class.methodName will refer to the instance method, and Class.static.methodName will refer to the class method. If methodName refers to a class method only, you can refer to it as Class.methodName, too.

An additional advantage is that the "old" way of declaring class methods (without using static) is deprecated, but it should still work; it is recommended to update to the new one, but do so at your own pace.

I've also made middleclass a single file, so it is easier to include - this should get rid of those "could not find middleclass" errors that some of you are experiencing. Also, I've included the license inside middleclass.lua, so the legal aspects are easier to handle now.

Should I use middleclass 2.0 on my new projects?

You should, unless you plan to use middleclass-extras; I haven't updated it yet. I will make another announcement when it is done. It's possible that middleclass-extras gets divided into smaller projects.

I'm using middleclass 1.4 on my project. Should I update?

Middleclass 1.4 is very tested, and it works just fine. There is no reason to rush to update, especially if you need middleclass-extras. However, keep in mind that I will not support that version in the future; In the unlikely event that you run into a bug, I might just point you to the new version. I don't have the means to support multiple versions simultaneously, since I do this in my free time. But as I was saying, 1.4 is very stable, and you shouldn't have any problems with it.

I hope this covers it. Feel free to ask if you have any questions!

Oh man, I'm an avid user of middleclass and stateful. Don't know what I would do without stateful!? It has ended up being the center piece of all my game state management.