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

[xStream 87]

К АМК 2.0 я не имею никакого отношения. Однако скрипты в нем, "переписанные с нуля", чуть более чем полностью такие же по сути, как в 1.4. Однако за 2.0 я ответственности не несу

 

На производительность, не важно в каком моде, при ОО подходе затраты идут на создание объектов. Но, зачастую, эти накладные расходы ничто по сравнению с временем выполнения рабочего кода. Главное не делать цикл на 100к итерций и не создавать там объектов Это раз.

 

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

 

Вывод - как в АМК 2.0 делать не надо. Надо знать ООП, а это уже явно выходит не только за пределы топика, но и форума

Изменено 1 Января 2012 пользователем xStream

[xStream 87]

ООП не относится к ЛУА. Это общая парадигма. Ее не расскажешь в двух словах и не научишь за 10 минут. Максимум, чему можно научить в пределах топика - базовым принципам использования готового кода с использованием готовых классов, кем-то написанных.

 

И созданных в самом 5.1.4 Без всякого luabind.

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

[xStream 87]

Конечно я понимаю что тот же luabind уже создан для... А как же искуство?

Искусство ради искусства? Я ничего против не имею. Только с этим вопросом (имитациия классов через метатаблицы) точно не ко мне. Я не настолько "продвинута" в этом вопросе. Да и сочинять велосипед не очень хочется

Насильно никто, никого, ни к чему не принуждает.

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

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

Программисты знают в первую очередь то, что используют. Я, например, про замыкания знаю и вовсю их использую, потому что в работе нужны. Метатаблицы ЛУА я знаю, и даже не в теории. Но повторять то, что сделано просто классно и офигительно - никогда не было желания. Ибо, скорее всего, я сделаю хуже и менее производительно.

Ещё раз повторю, - "А не для того ли топик, чтобы находить эти знания?".

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

Хорошо, делайте кому как хочется... А я уж буду по старинке...

Посижу в сторонке? Займусь велосипедами?

[xStream 87]

Ув. Artos, я не передергиваю. Все к тому и пришло: "есть два мнения, мое и неправильное". Не хочу дальше эту тему развивать.

А все остальное - слова, много слов. Не осилила прочитать, не обессудь

 

ЗЫ Пойду лучше оливье доедать.

Изменено 1 Января 2012 пользователем xStream

[xStream 87]

Хорошо, исправлюсь. А много буковок тут и читать-то особо некому Тем более, что их ты написал в ответ на мой пост. Не прокатила отмазка.

ЗЫ спасибо. Тебе желаю того же.

[xStream 87]

Я ругаю? Где? O_o

Я его наоборот использую вовсю и всем остальным советую (кто знает как использовать). Ты, видимо, что-то не так понял. Я ругаю то, как это используют. Вон, хвалят АМК 2.0 за "приятность для глаз". А по сути хлам как был, так и остался. Просто оно все аккуратнее смотрится из-за организации в виде классов. Но по сути это все то же процедурное программирование. Скажем так - забивание микроскопом гвоздей, использование не по назначению.

Просто подобный подход я видела не в одном языке и руки бы поотрывала а такое. Не знаете ООП - не трогайте классы.

[xStream 87]

Я не буду ни возражать, ни давать оценку.

На вкус и цвет фломастеры разные.

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

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

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

 

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

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

 

ЗЫ Ув. Artos, как бы то ни было, я имею полное право давать категоричную оценку тому, что было написано мной, не так ли? А код АМК и его последователя (и других модов, использующих куски АМК) в конкретном случае на очень неслабую часть - мой, спорить, надеюсь, не будем (моежете мне приписать огромное ЧСВ, если хотите)? Методики, использованые там, заложены Red75, sokol_jack и мной. Причем, скорее, в разных сферах и направленностях. Поэтому, я вполне в состоянии критически оценить и эффективность самих методик и их реализаций. Методики, подчеркиваю, и код для их реализации, остался по сути неизменным с тех времен по большей части. Хоть как перекомпонуйте, оберните в псевдо-классы, переназовите переменные и т.п. - суть остается той же.

Изменено 2 Января 2012 пользователем xStream

[xStream 87]

1) Не было, за исключением биндеров и всяких ГУИ - там наследование и там оправданное использование. Никто в модах ООП не пользовал в том понимании, какое заложено парадигмой.

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

[xStream 87]

Не стал пока поднимать этот вопрос, т.к. связан или нет тоже может быть субъективным понятием ... ;-)

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

....

Таймеры мне скоро плешь проедят Все зависит от принципа реализации. Делая один ивент "timer" (тут вообще напрашивается тогда вопрос - а нахрена тогда несколько объектов?), а внутри устраивая разбор полетов, - это одно, а использование объектов, не работающих вообще в принципе с ивентами - это другое. Правильнее всего, имхо, - создать систему объектов, которые просто проверяются на апдейт (вот тут то и нужна песочница и event-driven модуль), а к каждому присобачен колбек. Плюс таймер несет произвольные данные для срабатывания. Это позволит легко сохранять/восстанавливать, а срабатывать и вызывать напрямую. Тут вообще не особо нужна event-driven модель.

Изменено 4 Января 2012 пользователем xStream

[xStream 87]

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

2), 3) туда же... - описание механизма. Я не претендую на то, что это важные факторы и сама закрою на них глаза при гораздо более важных плюсах.

 

Я просто поддержала тему. Парадигма - не абстрактна, она описывает иерархию. Пример из реальной жизни: есть у тебя велосипед, двухколесный, красивый, 18 скоростей, тут ты прикручиваешь на руль стиральную машину, которая должна подключаться к электросети. Аналогия понятна?

Учитывая, что множественного наследования в ЛУА нет, то рано или поздно, как минимум уткнешься в вопрос - а что и от кого и зачем наследовать. Если делать "на всякий случай", то я не понимаю в этом ни логики, ни смысла. Подозреваю, что ты тоже не понимаешь, а именно "на всякий случай" случай делаешь. На всяких случай не делают. Добавляют не хватающее по мере необходимости, но никак не наоборот - не пихают все в кучу. Опять же, тебе нужны факты, аргументы. Есть аксиомы, заложенные таким подходом программирования. Не с того конца подходишь. Как сказал выше malandrinus, "уменьшить время разработки и/или уменьшить объём кода за счёт повторного использования готового кода." Могу только добавить "повторного использования там, где он нужен".

 

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

 

 

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

Во! Сообразила, как, наверное, правильно написать.

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

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

ЗЫ Еще раз акцентирую, дабы избежать очередной агрессии: это моя позиция, никому давно не навязываю даже.

[xStream 87]

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

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

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

ЗЫ Всех с наступившим!

[xStream 87]

http://dl.dropbox.com/u/46539648/xs_scripts.rar - библиотека для работы с нетпакетами. Зеркальное отображение АСДС, только в скриптах и ООП.

 

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

 

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

Изменено 7 Января 2012 пользователем xStream

[xStream 87]

Когда выложу, тогда все и расскажу

Размер практически не ограничен, но злоупотреблять не стоит. Вот пример тестов:

local function test()
    log1(">>>>>>>>>>"..tostring(get('test_2000', nil)))
    local k
    for k = 1, 2000 do
        set('test_'..k, 'long_test_string_value #'..k)
    end
end

local function test2()
    log1(">>>>>>>>>>dumping test table")
    
    print_table_inlog_v2(get('test_table', {}))
    
    local tbl = { 
        a = 1,
        b = {1,3,5},
        c = "abracadabra"
    }

    set("test_table", tbl)
end

 

В первом сосздается 2000 переменных с именами 'test_xxx' и значениями 'long_test_string_value #xxx'. Очень легко подсчитать объем, занимаемой этой ватагой переменных (38 байт * 2000 = 76000, почти что 70 с гаком килобайт)

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

 

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

Проверяет что value число? Почему б тогда не использовать обычный type()? Просто вот тут как раз не понял значения функции.

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

Не видела ни разу, чтоб мат функции юзали со строками, например.

ЗЫ Писать комменты на инглише - привычка уже просто Пусть даже мой инглиш далеко не идеален.

 

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

Кстати, о функции isnan. Дело в том, что есть такое значение NaN (Not a number). В стандарте RFC определено, что если сравнивать, что угодно с этим значением, то всегда получим false. Движок ЛУА это реализует (стандарт этот). И эта функцию это и использует. Потому что при любых других значениях переменная БУДЕТ равна сама себе. При этом type(math.nan) == 'number'. Во как, такой вот финт ушами. С бесконечностями, имхо, проще.

Изменено 7 Января 2012 пользователем xStream

[xStream 87]

Фидбек - это здорово.

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

Как написано в шапке - это своеобразный интерфейс (постаралась сделать простым для расширения) для "портирования" из АСДС. Так что если косяки, то все оттуда.

Я, конечно, еще проверю. Но что для ТЧ с версии 1.0004 и выше - точно.

 

Еще бы фидбек по использованию, но там, надеюсь, проблем не возникнет

 

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

Угу, что-то неактуальное, наверное, тот самый шотган:

use constant upd_properties_info => (
    { name => 'upd:ammo_ids', type => 'u8' },    # 0x1c0 (0x1e0)
);

Хорошо, что предусмотрен tail, по крайней мере данные не потеряются

Подкиньте ссылку на актуальную версию для ТЧ, 6-й патч. Универсальный не предлагать - я себе мозги сломаю заниматься переносом оттуда

Изменено 7 Января 2012 пользователем xStream

[xStream 87]

Дайте мне актуальную версию АСДС - будет А кто может сам исправить, спасибо скажу и исправления внесу.

да там и skeleton_flags в net_ph_skeleton хорошо бы разбирать по аналогии с num_items

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

 

ЗЫ Нету там таких констант, наврала. Опять же - все из АСДС, хехе.

 

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

Обновила архив, ссылка та же - http://dl.dropbox.com/u/46539648/xs_scripts.rar

Спасибо KD87, внесла изменения в соответствии с его замечаниями.

Изменено 7 Января 2012 пользователем xStream

[xStream 87]

У Artos'a они далеко неактуальные. А универсальный АСДС - слом мозга.

 

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

Со skeleton_flags не нашла ветвления в универсальном АСДС. Так что...

[xStream 87]

Йайа Вот за это и не люблю копипастить - легко что-то недосмотреть. Сенькаю, обновлено и залито.

 

ЗЫ Хочется фидбека по использованию, если кто решит попользовать. И всем спокойной ночи, кто в московском поясе

Изменено 7 Января 2012 пользователем xStream

[xStream 87]

Для пользования ими есть специальные функции хелперы ОЧЕНЬ сильно упрощающие жизнь. Когда будет дошлифовано содержимое, то будет и мануал (а пока можно поглядеть readme.txt, там вполне реальные примеры приведены).

Как минимум в одном моде уже используется (там люди знающие, поверь) и то радует - мои эксперименты не пропадут даром.

Изменено 7 Января 2012 пользователем xStream

[xStream 87]

xStream, возможно, я не совсем понял код, но вроде как в методе read класса "net_alife_item" нет чтения updposition и updquaternion. Они должны читаться в случае, если num_items ~= 0. Если равно нулю, ни updposition, ни updquaternion нет.

Что касается skeleton_flags, abramcumner прав, в acdc упрощено, сейчас приведу логику чтения.

Блин, я так спать не уйду

А это разве не оно?

        { name = 'ph_position',        type = 'f32v3', default = vector():set(0,0,0) },    
        { name = 'ph_rotation',        type = 'q8v',     default = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},     len = 4*4 },    --quaterinon

И

        if prop.name == "num_items" then
            updnum_items = ret["upd"..prop.name]
            if updnum_items==0 then
                return
            end
            info_mask = math.ceil(updnum_items/16)
            if not (bit_and(info_mask, 2)==0) then
                skip_props.ph_angular_vel = true
            end
            if not (bit_and(info_mask, 4)==0) then
                skip_props.ph_linear_vel = true
            end
        end

Вот условное чтение, в зависимости от updnum_items

[xStream 87]

Вот на pstor очень интересно посмотреть, особенно на запись таблиц. Сам давно уже пишу всё в текстовый файл но это накладывает определенённые ограничения (плюс я не знаю всех тонкостей функций чтения\записи что вывелось в не очень аккуратный код)

Интересно будет глянуть на твою реализацию, там тоже будет перевод таблицы в строку как в АМК?

А понять, как пишется очень просто Загляни в xs_helpers, там расширения для table есть: serialize и unserialize

 

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

Andrey07071977, таймеры, которые тут выкладывались - фигня, по ним не надо фидбека