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

[xStream 87]

Не знаю, насколько это актуально, но я часто использовала в последних своих изысканиях по сталкеру (но это относится к ЛУА в целом) следующее свойство: ключами и значениями у таблиц в ЛУА может быть что угодно. В качестве ключей можно использовать другие таблицы или функции! Это было откровение, и оказалось удобно.

 

Еще одним хорошим методом увеличения гибкости кода является использование безымянных функций, в частности, когда их передаешь как аргумент в другие функции. (Был уже пример, как я понимаю, - итератор). Получается неплохое такое приближение к полиморфизму в С++ (учитывая, что с помощью метатаблиц в ЛУА можно сымитировать классы и их поведение). Или, например, можно написать итератор по таблице, который будет выполнять функции, хранящиеся в таблицах-значениях, в зависимости от других значений этих таблиц или даже ключа (или выполнять ключ, если он является функцией). В общем - гибкость бешеная. Код, обычно, сокращался раза в 2-3. Есть только минус - отлаживать гораздо сложнее

[xStream 87]

Зачем? В зависимости от надобности.

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

[xStream 87]

Без кода, принцип:

 

Есть некая непись, она составляет рейд, причем в каждой точке (ключевой) планирует некое действие (например - отдельную схему, выполнение квеста и т.п.).

Действие - функция (у меня подставлялась в экшн), а параметры - "настройка действия" (типа надо пойти и найти такой-то предмет, отыграть такую-то анимацию и бляблябля).

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

При смене состояния (непись дошел до цели, например) делается next из таблицы, пишется в переменные (self.четотам, например). В эвалюаторе/экшене просто выполняется сохраненная функция с параметрами. В результате получается разнообразное поведение, в зависимости от того, что происходит вокруг непися и на контрольных точках. А схема - одна. Ну и никаких захардкоденых графов.

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

------

Поздно, я уже ответила

Изменено 6 Ноября 2011 пользователем xStream

[xStream 87]

Мне кажется, здесь проще всего составить функцию, в данном конкретном случае: деление на 10, получение целой части, отнимание 5, умножение на 500, обрезание с помощью min & max

[xStream 87]

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

В терминах ЛУА можно составить таблицу, каждый элемент которой содержит минимум и максимум, и значение. А там уж бегать по нему, пока не попадется нужное.

Или, как я выше писала, ключ - функция, которая вернет тру или фалс; если тру, берем значение и останавливаем перебор. Это более универсальное решение

[xStream 87]

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

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

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

Изменено 7 Ноября 2011 пользователем xStream

[xStream 87]

[offtopic]

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

Я придерживаюсь довольно строгих правил и требую от других того же (code guideline). Получается пока довольно эффективно. Начиная от именования переменных, до самодокументирования кода.

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

[/offtopic]

 

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

Тогда и не придется заниматься экономией на циклах (30% быстрее и т.п.), так как итерация по 100 элементам - совершенно не то же самое, что по 10 000, к примеру.

Это применительно и к сталкеру. Была мода в свое время пробегать по всем ИДшникам игровым с 1 до 65к, проще сделать один раз и составить таблицу, откуда удалять элементы и добавлять их туда уже по колбекам регистрации/разрегистрации. Это просто пример и мое имхо. Возможно, я отстала от жизни.

[xStream 87]

и не напасешься порой таблиц на все про все и не все в таблице учтешь.

Ну так и решение то не претендует на универсальность это как способ "оптимизации циклов" :-D ... оптимизации архитектуры.

 

Тут недавно про 'coroutine' GUN12 нам всем напомнил, и вышел довольно неплохой промежуточный вариант распределенного сканирования:

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

 

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

Изменено 7 Ноября 2011 пользователем xStream

[xStream 87]

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

Простое и отлаживать просто, бесспорно. Все зависит от мозгов программиста - чем он наполнит это все дело

 

ЗЫ Завязываю оффтопить

Изменено 7 Ноября 2011 пользователем xStream

[xStream 87]

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

Тем не менее, это инструменты, а речь шла о довольно примитивных техниках.

 

ЗЫ Все, точно завязываю Вернусь с чем-нить интересным, если вспомню. Просто некоторые вещи из Луа в принципе не подходят к сталкеру

[xStream 87]

xStream,

 

например?

 

Некорректно выразилась. Имелась ввиду основа связки С++ - ЛУА: экспорт функций, классов из С++ в ЛУА. Я просто привыкла к этому, на этом можно всяческие трюки сделать (включая работу с памятью, потоками и прочими интересными штуками). Здесь же, в сталкере, приходится иметь дело "с тем, что есть".

[xStream 87]

Да вы что? То, что не предусмотрено движком, через корявые дллки? Если да, то извините, но это рядом не валялось с написанием нормальной системы классов и их биндингом. У меня фантазия отказывает, бедная она у меня, походу. Или, может, расширение классов, описанных разработчиками? Тогда, конечно, это круто.

[offtopic]

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

[/offtopic]

[xStream 87]

Ок, я поняла точку зрения

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

 

Обкладывать сталкер дллками - палеатив, как я сказала. Да и вообще, такие таланты надо вкладывать не в чужое творение за бесплатно, а в свое и за деньги. Или я не улавливаю основную мысль? Сделать вообще возможно все, но вот есть ли в этом смысл...

[xStream 87]

Это стандартные функции ЛУА.

 

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

Изменено 15 Ноября 2011 пользователем xStream

[xStream 87]

Речь шла не о доступе к тому, что уже заложено в движке, а о новом функционале, причем экспортируемом в луа.

Это существенно разные вещи. Заняться реверсинжинирингом и дополнить существующее - бесспорно важно и полезно. Я тут даже и не спорю *тут должен быть смайл уважительного поклона*

Изменено 18 Ноября 2011 пользователем xStream

[xStream 87]

Операций goto и continue нет в ЛУА

[xStream 87]

[offtop]

Извините, но венгерская нотация - это полная жопа.

[/offtop]

 

Что касается песочниц, то... Вот мой вариант:

http://dl.dropbox.com/u/46539648/xs_sandbox.rar

В архиве - мануал и два примера.

[xStream 87]

Полная, полная.

От этих префиксов глаза устают, а мозги кучерявятся.

И вообще, было сказано на правах оффтопа, что уже подразумевает ИМХУ. Которое можно оспорить.

Если уж нужна аргументация, то лично я считаю, что семантика имен описывает код гораздо лучше, чем использование подобных префиксов. Главное подбирать семантически верные имена.

Например - name ну по любому строка по семантике, а bone_index - самодостаточное определение.

Спорить не хочу и не буду. Ибо ИМХО, как уже сказала.

 

И вообще, лучше б отписался по сендбоксу. У тебя критика конструктивная получается. :-P

[xStream 87]

Согласись, что читая: e, rev, obj, who

Это уже другой разговор. Пример приведен из того кода, где песочница используется. Причем, насколько я понимаю, это сделано как раз потому, что так ПРИВЫЧНЕЕ. Это ты фанат венгерки.

Т.е. зрительно восприняв начало слова - уже в мозгу откладывается и тип данных

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

Ваши префиксы, может и хороши, но семантикой ваш код тоже не очень то может похвастаться.

А вот привычное se_obj или soObj

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

 

Тут можно долго спорить. Дело предпочтений и привычек. Лично я предпочитаю использовать нечто, очень похожее на Google Code Guideline.

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

[xStream 87]

Так что чем махать шашками, стОит вчитаться именно в семантику фразы и принять во внимание НЕ тождественность понятий: 'привычное' и 'предпочтительное'. ;-)

Уважаемый, вот про шашки возвращаю фразу тебе. Это ты тут ими начал махать. Я преднамеренно обрамила свое высказывание в оффтоп, так что...

Как итог - я, камикадзе, мы твой код перевариваем с трудом. Тчк. Венгерка негласно принята устаревшей в том же Google Code Guideline. Пользуйтесь на здоровье, но помните - аргументировать пользу бесполезно. И холивор устраивать - тоже.

 

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

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

 

P.S. Кстати, пришло на ум: А почему ник xStream выбран той, кому такое написание (аля-венгерка) глаза режет? tongue.gif

Ник выбирался в те времена, когда я даже не занималась програмингом еще толком, не говоря о том, чтоб знать нотации и всякие прочие премудрости. Если всмотреться в СЕМАНТИКУ ( ), то видно зачем. Кроме того ник имеет двойной смыл при произношении (созвучен с - extreme), я люблю спорт - велик, ролики и т.п. Так что семантика в данном случае является основой. Ну и это ник, а не код

Далее - само такое написание (camelCase) мне глаза не режет, когда применяется к методам или именам классов (В ЛУА классов нет, поэтому "классы" я нотирую С-стайл). Ибо здесь оно несет другую смысловую нагрузку: а) само такое написание указывает, что имеем дело с методом объекта ( e:setFingerprint ), б) опять же - уже дело привычки насчет привычек я и не спорю. Но подавляющее большинство кода ( не моего, но который приходилось ревизировать) именно такой нотации и выдержаны. Венгерку я видела только в старых проектах. Что характерно - на префиксы там делается упор, а имена переменных сплошь и рядом несемантичны.

 

@>-`-,--`,--

Спасибо

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