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

[xStream 87]

в которой только в описании упоминается про hangCheck (в кодах ни разу).

В кодах каких? Оно использоваться должно там, где кидается ивент, а не где отрабатывается. Пример я в описании привела.

 

Добавлено через 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, сделала отрегистрацию, как ты просил. В любой момент. Надо помнить - передавать надо ТУ ЖЕ самую функцию, которая передавалась на регистрацию.

И применила этот подход в тестовых таймерах.

 

Все, что изменяла, засунула в архив с песочницей

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

[xStream 87]

Ты какую-то глупость пишешь.

hangChek - есть у объекта класса event всегда. Ты уверен, что смотришь последнюю версию?

Качай архив целиком! Я же написала, что все-все запихала в архив. http://dl.dropbox.com/u/46539648/xs_sandbox.rar. 404 - файл просто удален. Ибо если есть в архиве, то и не нужен отдельно

 

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

А что касается next, то я не знаю, что ты смотришь. Там все давно переделано на индексированный массив...

Надо архив посмотреть тебе. Актуализировать версию, а тогда уже будем дискутировать

 

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

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

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

[xStream 87]

Я сдержана и спокойна как удав. Просто я же тоже не просто так писала, что в архив все положила

А ты мне про 404. Из чего я делаю вывод, что смотришь ты не то. На фоне чего твои замечания теряют силу.

 

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

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

[xStream 87]

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

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

 

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

[xStream 87]

Вот именно - наследованием. А зачем? Что у них общего? НИЧЕГО.

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

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

 

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

Посмотрев твой код вижу новые методы типа проверки на зарегистрированность...

В общем, ты пошел старой знакомой дорожкой, а не той, что я закладывала.

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

Ну и конечно же - куда деться от 'uo'. Архинужная вещь.

Я считаю, что имею право на сарказм - я пыталась донести мысль, почему это все не нужно, почему надо организовывать так, а не иначе. В результате ты все равно делаешь, как раньше делал - плоский процедурный код. Который сводит на нет все идеи и профит.

[xStream 87]

Неправда Спроси у того же Камикадзе, есть ли проблемы с использованием в "кучерявой" игре, или нет.

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

 

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

Касательно таймеров - то был всего лишь пример. Я делала подобные объекты-таймеры так, что они "прицеплялись" к "объекту-носителю" и использовали его апдейт для своей работы, если таковой имеется.

Переделать тот код, что я в качестве примера привела - очень просто. Надо только мыслить в соответствующем ключе.

 

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

 

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

Ну спасибо за "чистую науку". И это ты мне говоришь, да? Пользуясь "наукой", мной написанной?

[xStream 87]

Зачем тебе каркас на базе ООП, если ты ООП не используешь?

 

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

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

 

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

[xStream 87]

Мне все равно, кто будет использовать и как.

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

[xStream 87]

Ну почему же. Я сужу по тому, что ты пишешь и выкладываешь (код). Я вполне ясно представила, каким путем ты идешь.

И это все - отнюдь не холивор. Я предприняла две попытки, аргумента, подкрепленные конкретными вещами - это разве холивор?

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

 

ЗЫ И почему это "ныне" ты не хочешь со мной холиворить?

[xStream 87]

Еще раз: я не против. Я наоборот радуюсь, если то, что я делаю, приносит пользу.

И не искажай мои слова. Чистота кода вполне уживается с его практичностью.

[xStream 87]

Не поняла пассажа про "в продолжение мысли "Чистота кода вполне уживается с его практичностью":"...

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

[xStream 87]

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

Но ты, уважаемый, занял сейчас паозицию попранной справедливости... Раз тебя раздражает эта тема, я больше не буду ее поднимать.

------------------

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

Извини, Артос, но на примере 'uo' рассмотрю Когда надо в функции чтоб было видно переменную, объявляем ее, потом функцию и вуаля - дополнительные параметры можно в функцию не передавать. Мда... наверное, плохо объяснила.

Но вот ссылка http://www.lua.org/pil/6.1.html/ тут очень наглядно показано применение и что это вообще такое.

 

ЗЫ Мне вспомнить холивор о "вкусах", касающийся венгерской нотации? Делая замечания окружающим, в упор не видишь бревна у себя в глазу...

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

[xStream 87]

Артос, припрячь ЧСВ, пожалуйста. Теме уже свернули шею.

Давай лучше вернемся к топику. Вот ты, например, пользуешься безымянными функциями? Теми же замыканиями? Кастомными классамии ООП?

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

[xStream 87]

"Потребуется" было в плане обсуждения таких фич. Насколько интересные вещи можно реализовывать и т.п. Описание можно просто выложить в виде ссылок.

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

 

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

[xStream 87]

Ну почему-же... Замыкания очень полезны, другое дело, что ты про них не знал Мне по работе приходится с ними работать в двух языках - и как раз в основном в колбеках (но не только!).

А пример я приводила как вариант замены твоим любимым 'uo' - вместо пачки переменных один объект-функтор. А) данные никак случайно не потеряешь, Б) защищены от изменения извне.

Для организации различных колбеков связка "безымянная функция + замыкание" вообще полезна очень. И не говори, что это теория. Это из практики. Все зависит от того, что ты хочешь реализовать.

А что касается "изюминки" - так в этом и есть суть топика: чем больше приемов знаешь, тем более эффективно можешь писать код. Пример один я привела.

 

Второй пример - диалоги имеют прекондишны, экшены и т.п. Фишка в том, что функции - first-class значения, их можно присваивать. Таким образом можно менять без каких либо мегаскриптов диалоги, меняя функции, например, так (все названия от балды):

dialog_functions.mega_dialog_1_rpg_precond = function () 
    ...
end

в файле dialog_functions функция mega_dialog_1_rpg_precond заменяется на другую.

Достаточно надуманный, но вполне реально применимый в жизни пример. (подобные фокусы с заменой функций я использую давно)

 

ЗЫ "в файле" - физически текст не изменится Просто в рантайме такая замена сработает. При каждой загрузке, правда, надо восстанавливать.

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

[xStream 87]

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

 

Остальное не буду комментировать, ибо это возвращение к закрытой теме.

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

[xStream 87]

2Artos

То ты призываешь давать конкретные примеры в конкретных ситуациях, то ударяешься в общие случаи. Ты уж определись. Панацеи не бывает. И я не навязываю никому ничего. Есть техника, я попробовала пример привести (лично тебе, я так поняла, вообще никакие примеры не работают, увы).

Все

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

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

-----------------

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

Другое дело, что в реализации, которую я представила, создаются ивенты с уникальными именами. Это неправильно. Но на то и пример. Он акцентирует внимание на другом.

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

[xStream 87]

Строчные ключи для "страховки". Специфика работы ЛУА... (изначально я реализовывала на table.remove, а это приводит к перенумерации числовых индексов) Я перестраховалась в данном случае. Вот откуда строковые ключи.

Цели примера: таймеры как объекты (ну не нужны им методы ивентов, не соглашусь с тобой, хоть убей), вложенные события - одни "выстреливают" другие, безымянные функции и замыкания (в принципе функторы - см. переменную local proxy = self и колбек с использованием этой переменной).

 

Кстати, очень хороший вопрос подняли - производительность. У "уберштуцернагибателей" есть существенная проблема - просадка производительности, если служебный код (менеджеры всякие, диспетчеры) обвешен кучей проверок и исполняется дольше, чем полезный, рабочий код. Вот это - действительно важный вопрос. Его бы обсудить, но тут примеров то и нет, и быть не может.

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

[xStream 87]

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

А в остальном я согласна - бесполезно, хотя это и очень важный вопрос.

[xStream 87]

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

Ладно, скатываюсь в оффтоп. Пойду к НГ готовиться, чего и вам желаю.