Ну, может быть. Просто я на swift постоянно с этим работаю, чтобы интерфейсы были чистыми. И пытаюсь понять можно ли вообще от этой концепции в lua получить какой-то прок. Ничего на ум не приходит, интерфейсов то как таковых нет, таблицы и ключи, и лишь какой-нибудь emmylua пропарсит все и подскажет где какой есть интерфейс )

Типа компилятор схавает все, поэтому не применимо

Как я понимаю, в данном контексте, интерфейс это некоторое соглашение на набор полей и методов.
Типа, если два класса имеют одинаковые методы (и/или связанные с ними поля) с однотипным вводом-выводом, то у них как бы есть общий интерфейс.

Может если с emmylua обертки какие делать, таблицы с интерфейсов протокола который будут закрывать собой реальные таблицы, пробрасывать. Я как и говорил выше, все это избвращение потенциально, но любопытно.

Верно. они поддерживают протокол. Типа "Да, мы это умеем".

А где-то снаружи ты с этим протоколои толкьо и работаешь, типа тебе не важно что там еще есть и что это вообще такое. Такая развязка от друг друга. Помогает еще в depency injection чтобы подставлять модули по протоколу, дисциплинирует разраба писать по полочкам.

> дисциплинирует разраба писать по полочкам
Вот это меня радует больше всего ))

По сути, основная проблема ООП в том, что его очень легко абузить так, чтобы код превращался в кашу из наследований, и хорошо если не множественных.
Основная проблема классического процедурного проганья ещё и в том, что оно даёт ну слишком много свободы, и для того чтобы структурированно писать нужно быть семи пядей во лбу, хорошо хоть у ООП нет такой проблемы.

И основной задачей новых модных методик становится сделать так, чтобы "при наших правилах не было принципиальной возможности написать криво или абузить наши правила".

Ну вот ктсати, с помощью протоколов в роли миксинов ты можешь ослабить наследование и вынести функционал "сбоку", более горизонтально )

Да, попытка придти к балансу. Чтобы и криво не было, и гибкость была.

Да фиг с ним с наследованием, по вопросу оно и не нужно нам ) Смотри, что у нас есть:

- идея фикс протокола countable, со свойством count: Int
- три таблицы. не суть какие они и зачем, но у двух есть свойство "count", а в третьей его нет. причем первая и вторая в остальном вообще про разное.

- задача чтобы нельзя было вставить куда-то свойством эту таблицы если они не имеет свойства count (не поддерживают countable) и как-то это удобно описать на lua. Попытка вставить третью таблицу выставит nil.
- задача чтобы эти две таблицы с count лежали в массиве и была уверенность что они туда попали так как поддерживают countable. и вытаскивая их оттуда мы работали с таблицей которая только лишь с этим свойством, а осатльное где-то зашито внутрь.

Т.е. по факту нам видимо нужны:
- сеттеры которые делают проверку на наличие свойств и типов
- геттеры которые возвращают обертку с интерфейсом протокола и в метатаблице держат ссылку на оригинал и дергают его по мере вызова методов протокола

Чтобы криво не было, достаточно не писать криво ))
Процедурным проганьем можно писать ровно и чисто. Сложно но можно. ООП можно сделать ровным, хоть это и набор ограничений "для бобиков" над процедурами. Почти что угодно можно сделать ровным, вопрос только в том, будут ли абузить правила это или нет (будут, инфа 100%).
И задачей становится ввод таких ограничений, чтобы абузить было НЕЛЬЗЯ СОВСЕМ, но при этом была "гибкость". Совсем в идеале, чтобы суперпрофессионал и новичок писали бы буквально одно и то же, ибо поддержка.

Ок ок, ну это сейчас не так важно. Давай задачу на lua решим, как тебе идея выше? )

Да норм, на подумать.

Всем привет, возможно ли выучить луа, за час, день?

За 15 минут даже: http://tylerneylon.com/a/learn-lua/

Ну всё равно нужно учить функции и тд

Код:

t = {
  a = 3,
  b = 4
}

for key, value in pairs(t) do
  print(key, value)
end

Почему вывод всегда разный?

a  3
b  4

b  4
a  3