Comment by Udo | Hacker News Reader

Comment by Udo | Hacker News Reader

Parent Full thread

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).

Hi there,

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 disagree. Learn the language and discover the new way of doing things it proposes. The approach Lua takes is very elegant, worth learning.

Mixins are a useful mental model for some kinds of code reuse though.

(I don't like his class style either, the constructor should return self, and I just like prototypal inheritance anyway).

> 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.

Not bashing PHP in any way (I'm a PHP developer myself), but what would you consider the PHP paradigm?

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.

Reply on news.ycombinator.com