Язык Lua. Общие вопросы программирования

[xStream 87]

xStream, осмелюсь все же спросить, а какова причина появления этого кода (сэндбокса)? Это из старых загашников или Вы вновь чуток пробуете кодить для Сталка? Готов в этом случае (для сэнд бокса) быть типа спаринг партнером (критиком) или просто партнером, дабы этот конструктор все же увидел свет (был реализован) в других модах ...

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

В принципе - это практически самоцель. Я написала под действием ностальгии, рада, если кому-то пригодится.

Часть замечаний справедлива, и в то же время - не очень. Дело в том, что это - концентратор. Тут все в одном месте и отслеживать это все можно легко и просто. Для отрегистрации модуля его достаточно тупо удалить (или переименовать, сменить расширение), и ничего не поломается. А что касается лога - даже спорить не буду. Мне нужно было отлаживать, я не хотела использовать никаких примочек никаких модов. Взяла то, что реализуется просто и не тянет зависимостей. Можете его убить у себя, если будете использовать. Что касается pcall, то я преднамеренно не стала оборачивать в него. Я считаю, что все-таки эта штука не для совсем новичков, хотя и может быть ими использована.

 

Только еще бы добавить функционала аля- подзабытый 'xrs_ai.script'.

А зачем? Это реализуется в виде модулей, которые либо есть, либо нет. Генерировать же можно абсолютно произвольные события типа "scheme_addCommonPrecondition" или "game_blowout". Кроме того, и это очень важный момент, у нас работа идет с объектом, который можно передавать по ссылке, а это значит, что если использовать альтернативное "выстреливание", то можно из события в месте, где выстрелили, получить, например, измененные данные. Ничто не мешает внутри обработчиков к ивенту присобачивать произвольные данные (или менять существующие - они, измененные, попадут в следующий обработчик). Я считаю, это неявной, но ОЧЕНЬ полезной штукой.

 

Ну зачем при 'data_table == nil'

Садись, два! © Ну да. Верно. ПО сути там есть несколько подобных штук некритического характера. По хорошему - из песочницы надо убрать все логи вообще. И натыкать проверок. Ибо в таком случае песочница станет багонепробиваемая Ведь она, по сути, должна просто транслировать события. При этом никак не должна реагировать или добавлять баги. Это мое мнение.

 

мною используется устаревшая рудиментарность - начну оббороняться

Да Боже упаси Никто не трогает венгерку.

Изменено 21 Декабря 2011 пользователем xStream

[xStream 87]

С учетом вышеоговоренного, и плюс кое-какие свои соображения привели к правкам - http://dl.dropbox.com/u/46539648/xs_sandbox.script

Что именно: багонепробиваемая песочница (мне все же импонирует это слово) - она просто проксирует вызовы. Включение/выключение модулей производится тупо удалением файлов или их переименованием, что НЕ требует правки конфига и избавляет от случайной возможности внести ошибку игроком (ибо он просто удалит файл-модуль). Для этой же цели, все сообщения идут только в лог, за исключением сообщений о повисании биндера. Поправила :trigger. Действительно, глупость была

[xStream 87]

А двойку - это зря-я-я

Это мне двойка Не тебе. Я учла и исправила

[xStream 87]

Это неправильно. Зависимостей должно быть минимум. И ничто не мешает использовать data-only скрипты. И использовать как в модуле, так и в других скриптах.

[xStream 87]

Кто сказал, что модуль должен состоять только из одного файла? Так, мысль на подумать.

Вторая мысль на подумать - разве речь шла о том, чтоб ВСЕ скрипты делать модулями?

Изменено 21 Декабря 2011 пользователем xStream

[xStream 87]

Неплохо бы все же добавть проверку на то, что передаваемые функции для регистрации в коллбэках проверялись бы на наличие.

Они проверяются, что являются функцией - достаточная проверка. И хранится не имя, а ссылка, прошу не путать.

 

Также не так редко, событие в одном модуле может потребовать регистрации в коллбэке некоей функции из другого модуля. Неплохо бы дать возможность регистрировать функции кросс-модульно.

Это тоже не запрещено. Использовать стандартное module.function

[xStream 87]

Ведь так более логично и оптимально:

Сделано по принципу "мухи отдельно, котлеты отдельно".

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

 

+ не обнаружил сброс прерывания коллбэка (self.__break), т.е. в последующих циклах уже не будут обрабатываться события - добавил сброс.

Не поняла. Какой сброс? Куда, зачем? Отработанное событие исчезает. В следующий раз создается новое, девственно чистое. Батенька, это ООП

 

Добавлено через 13 мин.:

А еще не поняла, зачем хранить в стеке работающих ивентов фингерпринт, а не само событие? Это даже более ресурсоемко...

 

Добавлено через 15 мин.:

Поняла, почему ты так сделал :-D

Ты, походу, не въехал в принцип, на котором работает это все добро. Концентратор существует всегда, событие - с момента создания, потом "выстреливает", проходят все обработчики, после этого событие отправляется в сборщик мусора.

Когда наступает снова такое же событие, создается новый объект-ивент.

Изменено 21 Декабря 2011 пользователем xStream

[xStream 87]

Ты вот зачеркнул про сброс, а зачеркнуть надо бы и остальное

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

ИМХО, конечно. Но это действительно делает код аккуратнее.

 

В С++ есть даже негласное правило - если метод состоит из больше чем 20-ти строк, то надо переписывать, или стараться оптимизировать.

 

P.S. А насчет "мух и котлет" - все же ситуация более похожа на "котлеты и соус" ... Кто-то предпочитает макать в соус, а кто-то сразу полить котлету им. :-)

Глупая игра слов. Я архитектор приложений уже три года. Насмотрелась всякого.

Изменено 21 Декабря 2011 пользователем xStream

[xStream 87]

Знаешь, пустое имя не является нарушением концепции. Именем может быть что угодно. Даже не строки, а маркерные константы, например. Это раз.

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

Изменено 21 Декабря 2011 пользователем xStream

[xStream 87]

2) там, где мы проверяем стек - это очень важный код. Когда произошло зависание ивента, он не будет пустым (стек) и раз уж дернули функцию trigger, то просто грех не проверить, а не поломался ли какой-нибудь биндер, понимаешь?

Мы проверяем на наличие незавершившихся ивентов, а не текущего.

То есть я про то место, не где мы помещаем в этот стек, а проверяем, не пустой ли он.

Изменено 21 Декабря 2011 пользователем xStream

[xStream 87]

Про регистрацию я не спорю, все верно. Лишнее действие.

А вот проверку - надо вернуть как было, чтоб всегда проверялось

 

Добавлено через 3 мин.:

Мог бы и не пояснять, я как бы не глупая, все поняла по коду

[xStream 87]

То, что было в амк - зачаточная идея, ну совсем зачаточная.

Если прикрутить к регистрации типа: function event:register(funct, uo)

Можно, но я что-то пользы в этом вообще не вижу ни малейшей. Так как ивенты очень четко таргетированы, при регистрации колбека мы всегда знаем, что будет вызвано. Зачем тогда еще и произвольные данные таскать?

Внутри песочницы придется реализовывать код, который будет заниматься сравнением и по сути выполнять e:stop(). Это логика явно не ядра. Каждый должен разгребать свое дерьмо сам, извиняюсь за такую метафору

Пример: подписана куча колбеков. Срабатывает ивент, попадается нужный ящик, стопаем процессинг очереди колбеков. Все, та же механика получается.

 

Про отрегистрацию мне вообще непонятно. Зачем? Зачем вешать избыточные одноразовые колбеки? Вот это мне действительно не понятно. Сделать то ее не сложно - функции можно сравнивать в ЛУА оператором ==.

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

 

Добавлено через 16 мин.:

Хотя ты мне подкинул одну очень интересную мысль

Надо покумекать...

Мысль следующая: подавать то можно и безымянные функции, что в принципе и приведет к тому, что можно это считать твоим юзер-обжект. А в объект-ивент добавить event:removeThis() - будет приводить к тому, что только что вызванный колбек после выполнения будет удален (отрегистирован).

Вот при таком подходе польза несомненна.

Изменено 21 Декабря 2011 пользователем xStream

[xStream 87]

Ты слишком узко мыслишь

Регистрацию колбеков, естественно, можно делать в любой момент, но не стоит забывать их заново биндить, если они еще нужны, на следующую загрузку.

То, что я описала выше, сделала. Получилось очень интересно, на мой взгляд.

Ссылка та же - http://dl.dropbox.com/u/46539648/xs_sandbox.script

Работает просто - неважно, как был зарегистрирован колбек, но можно после его выполнения его отрегистрировать, достаточно внутри него выполнить e:removeThisCallback()

 

Прогон "вхолостую", как ты выразился дает мизернейшие накладные расходы. Изучив природу ЛУА, я давно не занимаюсь такой дурацкой оптимизацией

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

 

И еще раз говорю - 'uo' не нужны. Пользуйтесь либо безымянными функциями, либо как то иначе организовывайте. НЕЛЬЗЯ ядро заставлять выполнять не свою работу.

 

Добавлено через 16 мин.:

Обновила сам архив, чтоб непоняток не было - http://dl.dropbox.com/u/46539648/xs_sandbox.rar

Изменено 21 Декабря 2011 пользователем xStream

[xStream 87]

Да я поняла, но произвольная отписка требует финтов ушами, а такая, как у меня - нет, она простая и семантичная.

[xStream 87]

Еще раз - основная идея: именно подключение произвольного кода с минимальными запарками. То, о чем ты говоришь, это уже совсем другое. Песочницу можно развивать, как угодно. Но я все же акцентируюсь на базовой идее. Назову ее - статическое связывание событий. Динамическое - это совсем другой разговор.

Изменено 22 Декабря 2011 пользователем xStream

[xStream 87]

Да, эту проблему я вчера увидела, пока думаю, как избавиться от нее малой кровью. Навскидку - введение у "корневых" событий дополнительного признака. Но это ugly решение, рушит концепцию простоты и универсальности.

 

И что значит - в сторону усложнения? Я наоборот всегда стремлюсь к упрощению интерфейсов

 

ЗЫ Ах да, обработчик зависших событий сейчас не работает из-за того, что массив неиндексированный, а ассоциативный... Я это у себя пофиксила. Решу проблему с "матрешкой" ивентов, тогда выложу решение.

Изменено 23 Декабря 2011 пользователем xStream

[xStream 87]

События из событий - это заложено в концепцию, но вот я лажанулась с проверкой подвисания - делала ее, когда не было этой возможности рекурсии.

 

Что касается входных параметров, то кто ж виноват, что уже была организована работа с переменным числом параметров, а тут вносятся такие изменения? Если систему (мод) строить изначально по одному какому-то принципу, то проблем не будет.

 

Добавлено через 12 мин.:

Вдогонку - интерфейс можно унифицировать, если из других мест передавать параметры тоже таким же объектом-событием. Но не выстреливать, а просто создавать, заполнять и передавать - получится унифицированность.

[xStream 87]

Ничто не мешает сделать event("xxxx"):register(yyyy) после старта игры.

Как я обращала внимание - это так называемые "статические" связи, те, что в init()

Изменено 23 Декабря 2011 пользователем xStream

[xStream 87]

Продумала семантику, ура. Выложу скоро свой вариант.

[xStream 87]

http://dl.dropbox.com/u/46539648/xs_sandbox.rar - смотреть мануал, в секции для "продвинутых", о том, как организовать проверки на зависание.

 

Добавлено через 2 мин.:

То, о чем ты говоришь - это надо организовать описания других классов. Могу сделать модуль таймеров. (без сохранения где либо, просто пример) Если хочешь.

 

Добавлено через 5 мин.:

Мне кажется, ты просто пошел не тем путем. В терминах игры и ООП, то, о чем ты говорил - так называемые стейты (загрузка, игра, сейв, ...).

Всякие таймеры - отдельные объекты должны быть. "Плоско-функциональный" подход здесь сделает кашу, на мой взгляд

Изменено 26 Декабря 2011 пользователем xStream