Курилка программистов

[Dennis_Chikin 3 658]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

А также про ООП, про как заниматься моддингом и его устарелости неустарелости,  кто как его себе представляет и т.д.  В общем, для много слов "обо всем". Что в более специализированные темы не лезет, но поговорить давно хотелось и хочется.

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[Desertir 202]

где надо остановится

on_drop_vodka_l02_garbage_day_rain_many_money_low_health

Ok?

[Карлан 1 049]

@Malandrinus, конкретно я в самом коллбеке определяю наиболее часто используемые параметры и кидаю их в ивент (это юзердата, айди и секция). Ну и далее можем легко и не принужденно вызывать:

function use(e)
return use_functions[e.section] and use_functions[e.section](e.obj) or log('warning: function not exist')
end

Ну и разумеется это все легко доделать до того, как сделано у Дениса (for i = 1, #t do t( item ) end).

 

И да, хоть расстреливайте не вижу ощутимого плюса в сравнении с e.section == 'my_item' and func(e). На мой взгляд так оно даже лучше, т.к. идентифицирующий параметр далеко не только секция может быть, так что городить еще один массив - мартышкин труд.

Изменено 5 Февраля 2015 пользователем Карлан

[Dennis_Chikin 3 658]

"т.к. параметр далеко не только секция." - остальное лично мне попадалось сильно реже.

Поэтому в запросах подписантов принимаются (и, соответственно, проверятся) только "по секции" или "любой".

 

А дальше то же самое можно повторить сколько угодно раз для любого количества параметров. Вот хоть как у Desertir.

 

e.section == 'my_item' and - вот здесь очевидно придется руками каждый раз лазить везде, где надо что-то добавить или убрать. Либо что-то нетривиальное творить.

 

 

Upd: Все, признаю. Вавилонское столпотворение свершилось, и с этого момента я ТОЖЕ уже перестал понимать, кто здесь вообще про что пишет, и что при этом имеет в виду.

Изменено 5 Февраля 2015 пользователем Dennis_Chikin

[Карлан 1 049]

@Dennis_Chikin, в таком случае можно просто через таблицу дополнительных параметров все что нужно докидывать, в этом и есть удобство.

event('drop'):register(drop, {param}, event, ...) 

И опять же не обременять себя построением массива. В случае с ивентами эти таблицы можно выстраивать прямо на ходу под нужды текущей функции/модуля. Далее их можно так же утилизировать без последствий, совсем. Изменено 5 Февраля 2015 пользователем Карлан

[Zander_driver 10 331]

 

 

Я недавно видел в одном скрипте как через loadstring вызывали функцию текущего скрипта в зависимости от аргумента, который формировал имя функции.

Не в моем, часом? у меня есть такое. Мог бы заметить.

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

[xStream 86]

На минуточку: в луа конструкция t[obj:section()] и набор колбеков со стоками типа if obj:section() == 'fuck_the_millenium" return end внутри выполнятся одинаково. Именно потому, что получение значения по ключу - тот же перебор, по хешмапу. А тут перебор колбеков до первого подходящего - та же табличка и то же сравнение. Разница только в дополнительном микросекундном вызове одной функции.

Вообще, знаете как работают конструкции типа t ?

Изменено 5 Февраля 2015 пользователем xStream

[abramcumner 1 141]

Именно потому, что получение значения по ключу - тот же перебор, по хешмапу.

Хмм... Не хилое такое заявление про хешмап и перебор.

[Zander_driver 10 331]

malandrinus, xStream. вообще-то t[obj:section()] собственно не для оптимизации нужен.

и размножение ивентов в биндере актора - не с той стороны вообще, от сути вопроса.

[xStream 86]

--тут был абсурд про хешмап, позор на мои седины--

 

вообще-то t[obj:section()] собственно не для оптимизации нужен.

А для чего тогда, если оно никаких преимуществ не даст? Хардкод даст, макаронный код даст, эффективность не даст. Профит в чем?

Изменено 6 Февраля 2015 пользователем xStream

[Dennis_Chikin 3 658]

Добавьте мне в if ... then ... elseif ... что-нибудь из скрипта.

Изменено 5 Февраля 2015 пользователем Dennis_Chikin

[Карлан 1 049]

@Zander_driver, я тебя тогда вообще не понимаю. Я тебе тогда тоже могу сказать, что делать много подписчиков или одного, тоже дело вкуса. Я могу сделать подписчика и передать ему в качестве аргумента всю твою таблицу с функциями (причем как глобальную, так и локальную, так и только что созданную), и мой подписчик будет пользоваться этой таблицей. Я что-то не пойму, ты америку открыть решил? С чего ты взял что такой расклад никто не берет во внимание? Вон сверху Аня все верно написала, и тут уже собственно сам сделай очевидный вывод.

 

Не в моем, часом? у меня есть такое. Мог бы заметить.

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

[abramcumner 1 141]

Хорошо-хорошо, не полный перебор. а бинарный поиск :-)

Это у map - бинарный поиск. У хешмепов время поиска ключу - константа.

[Zander_driver 10 331]

Если я тут еще появлюсь, напомните мне что я обещал тут не появляться.

to all: да окей, вы правы а я ничего не понимаю. я же и не спорил никогда с тем фактом что я начинающий и многое могу не знать или не понимать. как мне самому кажется лучше, так и делаю.

[Malandrinus 615]

размножение ивентов в биндере актора - не с той стороны вообще, от сути вопроса.

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

 

 

 

Позволю себе несколько пофилософствовать. Ивенты/события/сигналы/колбеки - это вообще реализация шаблона проектирования "наблюдатель". Суть идеи в том, что есть некий процесс, который идёт как идёт, и есть некое неопределённое заранее количество наблюдателей, других процессов, которые хотят что-то делать по факту происходящего в наблюдаемом процессе. Ключевое понятие здесь - "наблюдение", поскольку наблюдение неинтрузивно. Это означает, что наблюдаемый процесс ничего не делает для того, чтобы вызвать некие действия со стороны наблюдателя. И вообще не знает про наблюдателя, или наблюдателей, или их отсутствие, или что они собираются делать.

 

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

function actor_binder:on_drop(obj)
    ...
    if is_vodka(obj) and rainy_day() and self.object:money() > 100500 then
        some_module.gopstop_mi_podoshli_is_sa_ugla()
    end
    ...
end

будет явным нарушением этого принципа. С какой стати актору выдумывать себе неприятности? Иными словами, засорение логики актора не относящейся к нему логикой не есть хорошо. В биндере актора должно быть только то, что относится к актору (по-хорошему, почти ничего там быть не должно). Другой аспект - надо стараться уменьшать связи между разными компонентами, а здесь мы такую связь установили. Связи делают компоненты зависимыми друг от друга. Простейшая зависимость - удаление одного компонента приводит к неработоспособности другого. Я удалю модуль some_module.script и биндер актора будет валиться в месте обращения к нему.

 

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

 

function actor_binder:on_drop(obj)
    ...
    self.sm:call("on_drop", obj)
    ...
end

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

Изменено 6 Февраля 2015 пользователем malandrinus

[Карлан 1 049]

@Zander_driver, сначала говорить что все отсталые, и вообще кругом и везде всё не правильно делают, а потом съезжать на "я начинающий" - как минимум не корректно. Ты себе вот это вроде алиби придумал? Будь добр не прятаться в кусты, а ясно пояснить, что ты имеешь ввиду под "прогрессивным" использованием подобной системы на 2015 год. Ты можешь доказать состоятельность своей претензии, и описать альтернативно-лучший вариант? Я вроде тоже не дурак, и, если что, признаю свою неправоту. Пока я вроде-бы недвусмысленно дал понять, что с помощью ивентов гораздо удобнее манипулировать данного рода схемами, а так же при определенных действиях еще и память сэкономить. Как-нибудь опишу тебе еще некоторые плюсы, которые с ивентами делать куда удобнее, чем городить какие-то отдельные таблицы. Но у меня почему-то ощущение, что ты все равно будешь делать не как надо, а как тебе лучше кажется, притом называясь новичком... 

 

Ну и в догонку:

 

 

а писать в глобал или еще куда - какая в принципе разница, блин?)

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

http://www.lua.org/pil/4.2.html

[Malandrinus 615]

писать в глобал или еще куда - какая в принципе разница, блин?

Особенность Lua в том, что переменная ищется начиная от текущего уровня вложенности и вплоть до глобального, поэтому к глобальным переменным на самом деле обращение идёт медленнее. Но, на мой взгляд, это не самое важное. Важнее то, что глобальная область одна, и сваливать туда все переменные - чревато конфликтами по именам. Действительно лучше ограничивать область видимости, ну и как следствие время жизни, переменных.

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

Изменено 6 Февраля 2015 пользователем malandrinus

[Allender 11]

Здесь - смысла в таком нет. Хоть и через ивенты, но ваши исполняемые действия выглядят именно так как в приведенном примере. Хотя каждому "подписчику", нужен вполне определенный предмет, и не нужны все остальные.   Ну неужели так сложно сделать хотя бы так _g.script item_reactions = {     matras = function(obj)          end,     medkit = function(obj)          end,     bandage = function(obj)          end     ... } колбек на дроп или где там у вас производят это дело ивенты

 

Не есть хорошо. Например тебе нужны бинты и аптечки, а мне моя секция [beer], все равно придется править _g ручками.

 

 

self.am:call("on_drop_"..obj:section(), obj, sobj)

--Тогда для в модуле для подписки на событие дропа аптечки сделаем так:
function attach(sm)
    sm:subscribe({signal = "on_drop_medkit", fun = this.on_medkit_drop})
end
function on_medkit_drop(obj, sobj)
end

self.am:call("on_drop_"..obj:section(), obj, sobj) -- дроп предмета с секцией
self.am:call("on_drop_"..obj:clsid(), obj, sobj) -- дроп предмета какого-то класса
self.am:call("on_drop_"..(obj:mass() > 10 and "heavy" or "lightweight"), obj, sobj) -- дроп предмета массой больше/меньше 10-и кг 

 

А вот так можно?

function handler(obj)
	if obj.clsid = "WP_LR300" and ... then
		script.onDropSpecial();
	end
end

function onDropSpecial()
end

-- где-то...
self.am:call(loadstring("script.handler("..obj..")")); -- дроп предмета (неважно какого), обработчик разберется

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

 

-- upd:

Пардон, глупость написал с ..obj... Нужен же сам объект. Поправляюсь:

 

-- где-то...
self.am:call(loadstring("script.handler("..obj:id()..")")); -- дроп предмета (неважно какого), обработчик разберется

-- и в script
function handler(sId)
    obj = alife:object(sId);
    ...
end

Изменено 6 Февраля 2015 пользователем Allender

[xStream 86]

 

 

А вот так можно?

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

[Murarius 10 531]

Извините, я тут с оффтопом: в тег code добавлен выбор Lua.

 

 

Спасибо @Desertir за наводку.

 

Благодарю за внимание, продолжайте, пожалуйста.

[Dennis_Chikin 3 658]

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

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

 

Вот по-этому адресаты и не понимают, зачем им вообще пишут ЭТО, и что, собственно, хотят.

Вопрос - у кого-нибудь найдется время/желание написать все подробно и с самого начала ?

 

 

2 malandrinus: self.sm:call("on_drop", obj) - self. в примере как бы явно указывает на то, что относится к актору, а не к внешней системе, нет ?

Изменено 6 Февраля 2015 пользователем Dennis_Chikin