ООП в LUA и профит от него

Безотносительно к луа ООП понижает цикломатическую сложность кода в целом, позволяя писать куски кода разным людям или одному в режиме "по частям" и упрощая формальный анализ и покрытие тестами. Профит только в этом, все остальное рекламное бла-бла, в том числе НЕ быстрее, НЕ меньше памяти и даже НЕ меньше кода как такового (а обычно сильно больше). Соответственно, если вас данная проблематика не тревожит, можете не загоняться. По поводу "зачем оно есть именно в луа" - ну так вышло, что можно извернуться и сделать ООП, чего ж не возопить "у нас есть ООП".

Это просто очевидно. Возьмем C против C++, например. По памяти добавляются RTTI, таблицы виртуальных функций, таблицы исключений, код вызова деструкторов и конструкторов, не говоря уже о поддержке всего этого со стороны стандартной библиотеки. По скорости добавляются виртуальные вызовы, оверхеда немного, но он есть, а в случае dynamic_cast или множественного наследования оверхед уже значительный. В случае с луа ООП делается через метатаблицы, по памяти это плюс сама метатаблица, по скорости это плюс доступ к ней.

Если мыслью по древу растекаться, все упирается в мозги программиста. Теоретически сложную программу вроде квика можно спроектировать как единый конечный автомат, более того, как единый конечный автомат можно спроектировать систему квик-клиент + сеть + квик-сервер. Но практически никто такую модель в голове не сможет удержать, поэтому надо разделять ее на части. Разрезать можно только по коду, сохранив единый вектор состояния ("обычное" программирование с функциями), либо по коду и по вектору состояния (ООП). На практике вектор состояния режется и при обычном подходе, функции работают всегда с какой-то его частью, просто это делается неявно и ничто не мешает залезть из функции на "чужую территорию", ООП же запрещает такие поползновения.

В Lua, все же, прототипная модель ООП (https://ru.wikipedia.org/wiki/Прототипное_программирование). Если быть точным, в Lua все построено на таблицах. Поэтому думать о расходе памяти и оптимизировать код надо всегда (слабые таблицы).
Поэтому Классы в Lua решают больше задачу создания некой сущности на основе шаблона. Что бывает удобно. Но все то же можно сделать и без оного, придется просто сделать больше переменных.

Ну и для примера. У меня в одной из библиотек реализован класс "Ордер". У него есть методы и свойства общие для ордеров.
У него два наследника - "Лимитные ордера", "Стоп ордера". У них уже есть свои, характерные именно для них, методы и свойства.
Это позволяет работать с ордером как с объектом, а не просто как строка в таблице Квика. А методы позволяют реализовать интерфейс к ордеру, в понятных и общих терминах.

со стороны виднее

мой пост был с учетом уже имевшегося ответа от Антона.именно это мной и имелось ввиду. это грубая ошибка. нет сомнений.

например, чтобы понять неправоту и исправится. или не понять.

точно, возле ваших ромашек.

много лет мну объяснял друзьям и близким что открывашка - жулики, а кризис будет жесткий.

верю, что вам видно именно так как вы и говорите. мне собственно пофиг. как и нынешние проблемы тех, кто слушал, но не слышал.

jedem das seine.