I've bee studying Lua very thoroughly recently because I'm working on a toy language based on its runtime, so I gained a certain appreciation for some of the concepts Lua uses.
Given this background and my general coding experience up to now, I'm very skeptical about OO frameworks for Lua, because they mostly provide mechanisms that are neither true to the language's design nor are they really necessary. Specifically, mix-in patterns are extremely easy to implement just using core features already present.
Most languages work best if you don't try to forcefully adapt them to emulate another language. In my opinion, some of the worst features in both PHP and JavaScript come from a more or less hidden desire to mimic Java instead of being confident in the paradigms those languages already provide.
Lua already allows you to share code between "objects", and it allows you to do that with excellent granularity, simplicity, and a lot of control. There is no question that Lua is well-suited for modification and can be adapted for many things, but in this case I'm having trouble seeing the benefit (other than perhaps a programmer's familiarity with "standard" OO design which can be a considerable boon in the short term).
> Mixins are a useful mental model for some kinds of code reuse though.
They are, but I can think of at least one core feature-based solution to do the same thing with less overhead. Each mix-in or trait could easily be in its own table, to be joined with the object as it's being constructed in whatever fashion desirable.
I like PHP as well, however it's the wrong language to build byzantine OO inheritance structures in. Yet, that's what new feature development seems primarily directed at: new OO functionality that adds a lot of complexity and new opportunities for developers to shoot themselves in the foot. Listening to PHP core developers' presentations, I get the impression they're trying to imitate Java.
The per-request execution model can be played as an incredible strength, but the moment some framework comes along, starting off by loading all of its code, then instantiating a myriad classes, subclasses, traits, and other crap just to serve a simple request - that's where slowness and bugginess comes from.
I think simple objects do work well in PHP, together with judicious use of the powerful array data structure, anonymous functions, and on-demand code loading.
> The per-request execution model can be played as an incredible strength, but the moment some framework comes along, starting off by loading all of its code, then instantiating a myriad classes, subclasses, traits, and other crap just to serve a simple request - that's where slowness and bugginess comes from.
Really good point, never thought about it this way.
I am the author of the OOP library mentioned on the article.
> I'm very skeptical about OO frameworks for Lua
Me too :)
I think Lua OOP libraries are great in two particular circumstances: for people coming from OOP languages, when starting working with Lua, they serve as a "crutch"; they allow you to start working in a language with paradigms that you are not familiar with with a set of structures you are familiar with.
Later on, once you are familiar with Lua's metatables, you can do most things with plain Lua. 90% of the time, it's just enough.
The remaining 10% comes when you need really advanced stuff - for example, class methods called the same as instance methods in class. Or operator inheritance. Then using a library like middleclass is worth the increase in complexity and the extra dependency.
TL;DR: Use middleclass at the beginning, when you are learning, or at the end, when you need advanced stuff. Don't use it if you just need 1 line of metatable stuff and you know how to implement it in raw Lua.
It would be better if this article had been using real Lua code, and not starting with a "class" function. Lua does !NOT! have classes. Lua is a prototyping language, and anybody can handwave an own class system, or go without classes at all. The idea of mixins makes only sense in languages that have classes. Lua does not. References have a metatable, and this metatable contains functions. The functions are independent of the reference, and there are no classes. So basically all functions in a metatable are mixins by default.
Best Lua "class" example I've seen is in the PIL 3rd edition it is about 10 lines of code and lets you use inheritance and some other nice OOP concepts.
This is a boring view! All the same concepts of classes, interfaces, objects still exist when using Lua, you just don't have a canonical implementation. This is also interesting in itself -- the best class system may spread and be improved.
I am the author of the library mentioned in the article (not the article author, that's someone else). You seem to have missed the link to the OOP library used, so here it is:
Also, notice that in other comments on this thread I mention that I don't think OOP in Lua it's a one-size-fits-all thing. I think middleclass has its uses, but most of the time plain Lua with some metatables does the trick just fine.
Wait. Just having a glance at the website, and I see these animations - do they have anything to do with the code? It doesn't quite clearly state that and I'm kind of put off reading the code. :-/ Sorry if I've missed something.
I believe we spoke about this very subject in reddit not long ago. In that conversation I mentioned that I'd rather use composition instead of mixins for most of the examples you made.
Rather than repeating myself, here's the link, in case someone wants to see an alternative approach:
I've always found mixins in other languages to be absolutely horrible in terms of maintainability. They often lead to all sorts of sins and junk-drawer design. I'd prefer to see something like a clojure-ish protocol library.
24 comments
[ 0.19 ms ] story [ 55.1 ms ] threadGiven this background and my general coding experience up to now, I'm very skeptical about OO frameworks for Lua, because they mostly provide mechanisms that are neither true to the language's design nor are they really necessary. Specifically, mix-in patterns are extremely easy to implement just using core features already present.
Most languages work best if you don't try to forcefully adapt them to emulate another language. In my opinion, some of the worst features in both PHP and JavaScript come from a more or less hidden desire to mimic Java instead of being confident in the paradigms those languages already provide.
Lua already allows you to share code between "objects", and it allows you to do that with excellent granularity, simplicity, and a lot of control. There is no question that Lua is well-suited for modification and can be adapted for many things, but in this case I'm having trouble seeing the benefit (other than perhaps a programmer's familiarity with "standard" OO design which can be a considerable boon in the short term).
(I don't like his class style either, the constructor should return self, and I just like prototypal inheritance anyway).
They are, but I can think of at least one core feature-based solution to do the same thing with less overhead. Each mix-in or trait could easily be in its own table, to be joined with the object as it's being constructed in whatever fashion desirable.
The per-request execution model can be played as an incredible strength, but the moment some framework comes along, starting off by loading all of its code, then instantiating a myriad classes, subclasses, traits, and other crap just to serve a simple request - that's where slowness and bugginess comes from.
I think simple objects do work well in PHP, together with judicious use of the powerful array data structure, anonymous functions, and on-demand code loading.
Really good point, never thought about it this way.
I am the author of the OOP library mentioned on the article.
> I'm very skeptical about OO frameworks for Lua
Me too :)
I think Lua OOP libraries are great in two particular circumstances: for people coming from OOP languages, when starting working with Lua, they serve as a "crutch"; they allow you to start working in a language with paradigms that you are not familiar with with a set of structures you are familiar with.
Later on, once you are familiar with Lua's metatables, you can do most things with plain Lua. 90% of the time, it's just enough.
The remaining 10% comes when you need really advanced stuff - for example, class methods called the same as instance methods in class. Or operator inheritance. Then using a library like middleclass is worth the increase in complexity and the extra dependency.
TL;DR: Use middleclass at the beginning, when you are learning, or at the end, when you need advanced stuff. Don't use it if you just need 1 line of metatable stuff and you know how to implement it in raw Lua.
I am the author of the library mentioned in the article (not the article author, that's someone else). You seem to have missed the link to the OOP library used, so here it is:
https://github.com/kikito/middleclass
Also, notice that in other comments on this thread I mention that I don't think OOP in Lua it's a one-size-fits-all thing. I think middleclass has its uses, but most of the time plain Lua with some metatables does the trick just fine.
So it's basically like "a taste of the world of Lua" or something like this, to make the presentation less dry.
Thanks for writing this article.
I believe we spoke about this very subject in reddit not long ago. In that conversation I mentioned that I'd rather use composition instead of mixins for most of the examples you made.
Rather than repeating myself, here's the link, in case someone wants to see an alternative approach:
http://www.reddit.com/r/gamedev/comments/1uni58/the_power_of...