xStream

Не надо пример с таймерами брать как жизненный, плиз :-D На то и пример, написанный за 10 минут, доведенный до рабочего состояния более-менее и имеющий чисто академическое назначение. А в остальном я согласна - бесполезно, хотя это и очень важный вопрос.

Строчные ключи для "страховки". Специфика работы ЛУА... (изначально я реализовывала на table.remove, а это приводит к перенумерации числовых индексов) Я перестраховалась в данном случае. Вот откуда строковые ключи. Цели примера: таймеры как объекты (ну не нужны им методы ивентов, не соглашусь с тобой, хоть убей), вложенные события - одни "выстреливают" другие, безымянные функции и замыкания (в принципе функторы - см. переменную local proxy = self и колбек с использованием этой переменной). Кстати, очень хороший вопрос подняли - производительность. У "уберштуцернагибателей" есть существенная проблема - просадка производительности, если служебный код (менеджеры всякие, диспетчеры) обвешен кучей проверок и исполняется дольше, чем полезный, рабочий код. Вот это - действительно важный вопрос. Его бы обсудить, но тут примеров то и нет, и быть не может.

2Artos То ты призываешь давать конкретные примеры в конкретных ситуациях, то ударяешься в общие случаи. Ты уж определись. Панацеи не бывает. И я не навязываю никому ничего. Есть техника, я попробовала пример привести (лично тебе, я так поняла, вообще никакие примеры не работают, увы). Все Ты одновременно и частность охватить пытаешься и все сразу. Нельзя идти во все стороны разом. Есть техника, есть конкретный пример. Данные из функтора не нужно вынимать, так как они, в первую очередь, если вспомнить назначение юзер-обджекта, используются только внутри него же. Ты сейчас пытаешься спорить в общем... Не надо. Я спорить не собираюсь ни с кем. Это слишком нервный процесс. Про замыкания сказала, про безымянные функции - тоже. Про классы - очень большой и отдельный разговор. Тут примеры надуманные вряд ли приведешь. ООП в скриптах сталкера не было никогда. Только для наследования, но мы это не берем в расчет. Я на этом внимание акцентировала. Потому что объекты таких классов не используются нигде. Только как сами по себе. ----------------- Заниматься оптимизацией индексов - реально глупая задача, потому что числа эти очень большие (ограничены разрядностью приложения) и я вот уверена - 4млрд - хватит выше крыши. При следующей загрузке, переходе на другой уровень и т.п. все это добро инитится заново, начиная с нуля. Не наберешь ты 4 млрд. Есть золотое противоречивое правило программиста, состоящее из двух пунктов: а) всегда оптимизируй, б) не оптимизируй раньше времени. Я исхожу из этого правила. Я даже в теории не могу представить 4 миллиарда таймеров в течение игровой сессии. Вообще никак. Другое дело, что в реализации, которую я представила, создаются ивенты с уникальными именами. Это неправильно. Но на то и пример. Он акцентирует внимание на другом.

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

Ну почему-же... Замыкания очень полезны, другое дело, что ты про них не знал Мне по работе приходится с ними работать в двух языках - и как раз в основном в колбеках (но не только!). А пример я приводила как вариант замены твоим любимым 'uo' - вместо пачки переменных один объект-функтор. А) данные никак случайно не потеряешь, Б) защищены от изменения извне. Для организации различных колбеков связка "безымянная функция + замыкание" вообще полезна очень. И не говори, что это теория. Это из практики. Все зависит от того, что ты хочешь реализовать. А что касается "изюминки" - так в этом и есть суть топика: чем больше приемов знаешь, тем более эффективно можешь писать код. Пример один я привела. Второй пример - диалоги имеют прекондишны, экшены и т.п. Фишка в том, что функции - first-class значения, их можно присваивать. Таким образом можно менять без каких либо мегаскриптов диалоги, меняя функции, например, так (все названия от балды): dialog_functions.mega_dialog_1_rpg_precond = function () ... end в файле dialog_functions функция mega_dialog_1_rpg_precond заменяется на другую. Достаточно надуманный, но вполне реально применимый в жизни пример. (подобные фокусы с заменой функций я использую давно) ЗЫ "в файле" - физически текст не изменится Просто в рантайме такая замена сработает. При каждой загрузке, правда, надо восстанавливать.

"Потребуется" было в плане обсуждения таких фич. Насколько интересные вещи можно реализовывать и т.п. Описание можно просто выложить в виде ссылок. Например, как я приводила пример - можно очень комфортно и удобно сделать функцию обертку, внутрь которой засунуть какие-то переменные, которые будут использоваться в еще одной функции (надо смотреть линк про замыкания. Там очень классные примеры). Таким образом мы получим так называемый функтор - объект-функцию, которая может быть выполнена и в то же время несет какие-то данные. ЗЫ Кастомные ООП классы - я так обозначила новые классы, которые были описаны и использованы в игре НЕ АВТОРАМИ игры И которые действительно представляют собой реализацию парадигмы, а не псевдо-ООП (структурный подход), когда создается класс, а в него тупо фигачатся функции, которые в принципе можно сддеать и свободными (при таком подходе получается просто группировка функций, не более. Объекты таких классов малофункциональны сами по себе и обозначают скорее некий неймспейс)

Артос, припрячь ЧСВ, пожалуйста. Теме уже свернули шею. Давай лучше вернемся к топику. Вот ты, например, пользуешься безымянными функциями? Теми же замыканиями? Кастомными классамии ООП? Эти вопросы обусловлены темой топика и количество мнений должно быть больше, чем одно - мое Если потребуется, могу расписать про подобные вещи чуток.

Нет, не кажется Я не оставляю попыток показать, что делать убер-пупер-мегаскрипт - не панацея, зачастую приводящая вообще к ужасному нагромождению кода. Ты же этого в упор не хочешь видеть. Но ты, уважаемый, занял сейчас паозицию попранной справедливости... Раз тебя раздражает эта тема, я больше не буду ее поднимать. ------------------ А теперь вернемся к теме топика. В ходе ковыряния песочницы, выяснилось, что в ЛУА таки есть замыкания (closures). Это такая ситуация, что переменные, которые были "видны" при объявлении функции, могут быть в ней использованы. Кроме того - эти переменные существуют, пока на них ссылается эта функция. Очень, очень удобно. Извини, Артос, но на примере 'uo' рассмотрю Когда надо в функции чтоб было видно переменную, объявляем ее, потом функцию и вуаля - дополнительные параметры можно в функцию не передавать. Мда... наверное, плохо объяснила. Но вот ссылка http://www.lua.org/pil/6.1.html/ тут очень наглядно показано применение и что это вообще такое. ЗЫ Мне вспомнить холивор о "вкусах", касающийся венгерской нотации? Делая замечания окружающим, в упор не видишь бревна у себя в глазу...

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

Еще раз: я не против. Я наоборот радуюсь, если то, что я делаю, приносит пользу. И не искажай мои слова. Чистота кода вполне уживается с его практичностью.

Ну почему же. Я сужу по тому, что ты пишешь и выкладываешь (код). Я вполне ясно представила, каким путем ты идешь. И это все - отнюдь не холивор. Я предприняла две попытки, аргумента, подкрепленные конкретными вещами - это разве холивор? И я пришла к выводу, что ты решил сделать очередной уберскрипт все-в-одном. Не это являлось целью исходного моего скрипта. Совсем не это. Но, как я уже написала, аргументы, на мой взгляд достаточно убедительные, так как идут с подтверждением примерами, не сработали. Так что... ЗЫ И почему это "ныне" ты не хочешь со мной холиворить?

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

Зачем тебе каркас на базе ООП, если ты ООП не используешь? Мы об идее. Ты бил себя пяткой в грудь "будет топик, научим людей". Чему? Кучерявостям? Твоему способу написания кода? Может лучше просветление внести в мозги, новые идеи, которые работают, как ни странно? Да, я навязываю, потому что это моя идея, она самодостаточна. Ты уперся лбом и не хочешь принимать идею, что не надо разные сущности объединять в одну. Потому что в результате получается каша. И проще организовывать код от этого не становится. Возвращаемся к тому, что существует уже несколько лет в сталкере - хаос в коде, зависимости и полная каша. Вот пользователей не надо сюда приплетать Игроки играют, начинающие ваяют по туториалам. И какой ты им дашь, тот и заюзают.

Неправда Спроси у того же Камикадзе, есть ли проблемы с использованием в "кучерявой" игре, или нет. Вывод простой - это ты так накучерявил свой код, что просто иначе не можешь организовывать код. Еще раз - ООП вполне рулит. И не надо утверждать, что никак не уйти. Это ты так реализовал, но это далеко не истина и не оптимальное решение. Касательно таймеров - то был всего лишь пример. Я делала подобные объекты-таймеры так, что они "прицеплялись" к "объекту-носителю" и использовали его апдейт для своей работы, если таковой имеется. Переделать тот код, что я в качестве примера привела - очень просто. Надо только мыслить в соответствующем ключе. Но, конечно же, проще использовать то, что было раньше. Вопрос - зачем ты тогда вообще взял эту песочницу, если все равно приводишь ее к процедурному виду? Добавлено через 1 мин.: Ну спасибо за "чистую науку". И это ты мне говоришь, да? Пользуясь "наукой", мной написанной?

Вот именно - наследованием. А зачем? Что у них общего? НИЧЕГО. Если делать ООП, то делать по всем правилам, а не абы как. Потому что таймеры - это генераторы событий, но никак не события. Я, конечно, могу долго распинаться, но, чувствую, это будет бесполезно - вторая попытка донести идею профейлилась напрочь. Добавлено через 5 мин.: Посмотрев твой код вижу новые методы типа проверки на зарегистрированность... В общем, ты пошел старой знакомой дорожкой, а не той, что я закладывала. Да и организация параметров - это ужас какой-то. Переменное количество параметров, конечно же лучше, чем набор методов для выставления величин (это сарказм был). Ну и конечно же - куда деться от 'uo'. Архинужная вещь. Я считаю, что имею право на сарказм - я пыталась донести мысль, почему это все не нужно, почему надо организовывать так, а не иначе. В результате ты все равно делаешь, как раньше делал - плоский процедурный код. Который сводит на нет все идеи и профит.

А очень простая: при моем подходе порядок сохраняется, а при использовании next ЛУА не гарантирует, что элементы достаются по порядку. Недостаток у next такой же, как у pairs. А если я хочу развернуть стек вложенных ивентов, в результате которых произошло зависание, то хорошо бы показать "матрешку" в том порядке, как все вызывалось.

Я сдержана и спокойна как удав. Просто я же тоже не просто так писала, что в архив все положила А ты мне про 404. Из чего я делаю вывод, что смотришь ты не то. На фоне чего твои замечания теряют силу. Добавлено через 6 мин.: Хочу добавить, что таймеры специально сделаны не самым оптимальным способом, чтоб показать динамическую связку.

Ты какую-то глупость пишешь. hangChek - есть у объекта класса event всегда. Ты уверен, что смотришь последнюю версию? Качай архив целиком! Я же написала, что все-все запихала в архив. http://dl.dropbox.com/u/46539648/xs_sandbox.rar. 404 - файл просто удален. Ибо если есть в архиве, то и не нужен отдельно Добавлено через 9 мин.: А что касается next, то я не знаю, что ты смотришь. Там все давно переделано на индексированный массив... Надо архив посмотреть тебе. Актуализировать версию, а тогда уже будем дискутировать Добавлено через 3 мин.: Предлагаю переместиться в аську, если процесс установления абсолютной истины слишком медленен

В кодах каких? Оно использоваться должно там, где кидается ивент, а не где отрабатывается. Пример я в описании привела. Добавлено через 9 мин.: http://dl.dropbox.com/u/46539648/xs_timers.script - пример таймеров, как обещала. НЕОПТИМИЗИРОВАНО! Все повешено на актора. Кроме того, не уверена в том, как работают замыкания в ЛУА, так что function timer:run(time_seconds) - под вопросом, но суть такая. Я просто в этом примере пытаюсь показать, что незачем смешивать различные сущности и пихать все в одно место. Добавив колбеки на запись/загрузку нетпакетов, можно вполне организовать и запись и восстановление таймеров. Правда придется переделывать организацию колбеков. Но это уже другой разговор. Добавлено через 7 мин.: Пример использования: local kill_timer = timer() kill_timer:bind(kill_object, function(object) object:kill(object) end) kill_timer:run(10) Через десять секунд после запуска таймера, помрет непись kill_object. Добавлено через 72 мин.: Ура, замыкания рулят - http://www.lua.org/pil/6.1.html Значит код рабочий. Добавлено через 39 мин.: Artos, сделала отрегистрацию, как ты просил. В любой момент. Надо помнить - передавать надо ТУ ЖЕ самую функцию, которая передавалась на регистрацию. И применила этот подход в тестовых таймерах. Все, что изменяла, засунула в архив с песочницей

http://dl.dropbox.com/u/46539648/xs_sandbox.rar - смотреть мануал, в секции для "продвинутых", о том, как организовать проверки на зависание. Добавлено через 2 мин.: То, о чем ты говоришь - это надо организовать описания других классов. Могу сделать модуль таймеров. (без сохранения где либо, просто пример) Если хочешь. Добавлено через 5 мин.: Мне кажется, ты просто пошел не тем путем. В терминах игры и ООП, то, о чем ты говорил - так называемые стейты (загрузка, игра, сейв, ...). Всякие таймеры - отдельные объекты должны быть. "Плоско-функциональный" подход здесь сделает кашу, на мой взгляд

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

Ничто не мешает сделать event("xxxx"):register(yyyy) после старта игры. Как я обращала внимание - это так называемые "статические" связи, те, что в init()

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

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

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