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

[Dennis_Chikin 3 658]

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

 

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

 

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

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

[Dennis_Chikin 3 658]

Пример странного был в древнемодах. Водка и энергетик.

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

 

О, еще "телепорты"...

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

[xStream 86]

 

 

Водка и энергетик.

Это объекты с разными секциями. Собственно все

И все перечисленное тоже легко разносится по какому-либо признаку.

[RayTwitty 492]

Как я себе вижу использование этих самых ивентов:

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

 

Но, рассмотрим другую ситуацию: если я делаю проект, где количество этих самых фич конечно, то есть я знаю, что мне надо будет сделать вот это, это и ещё вот это, то мне будет куда проще сделать простое подключение через обыкновенный вызов, чем писать динамическую систему. Мой проект создается для пользователей (игроков) и собственно для игры, зачем мне делать какую-то универсальность и модульность?

 

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

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

[xStream 86]

, нифига. Это просто удобно. Для себя тем более, выше даже примеры приводились.

Изоляция и локализация важных мест - это круто, удобно и эффективно.

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

[Dennis_Chikin 3 658]

2 Shadows, вообще-то тут меня били ногами за предложенные "промежуточные" решения.

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

 

Типа, "разнести по секциям" и т.д. Да и не только меня. А также пинали кто попало кого попало и за "переусложнения". Но это так, лирика.

 

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

Вот все то же банальное for i = 1, #t do t().

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

 

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

 

 

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

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

 

По тому как ну в общем-то очевидно, что именно это и было написано "от переборов не уйти". И так же совершенно очевидно, что отнюдь не имеется в виду набивание руками некоей таблицы t, а что-то типа t = {}; function subscribe_on_something( ptr ) table.insert( t, ptr ) end

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

 

 

"мегасистем" - это любые комплекты любых оберток поверх того перебора, от которого не уйти, с любым дополнительным функционалом, общим объемом более страницы.

 

"Главный цимес, что можно это делать динамически" - О !!! Неужто договорились ?

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

[xStream 86]

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

Правда, что ли? :-) Рефакторить микросекундные вызовы? Заниматься копипастой? Нененедевидблейн

Вот все то же банальное for i = 1, #t do t().

Да тащемто нет. Подписываются только те, кому надо. И от подобных переборов ты никуда не уйдешь.

Главный цимес, что можно это делать динамически (и вот такие реальные случаи были у меня)

мегасистем

это, кстати, что такое? Изменено 4 Февраля 2015 пользователем xStream

[Zander_driver 10 333]

Надо бросать курить...

Ой, а я и не курю же.

[Desertir 202]

О !!! Неужто договорились ?

Ну как бэ система ивентов подразумевает и подписку и отписку от события, кто то говорил, что она сугубо статическая? Типа запалил гдето свой номер мобильника и получаешь ежедневно СеМеСески с рекламой Да собстно подписка это тоже динамика.

 

У мине вопрос, об чем спор уже сейчас? Если на странице ранее еще было понимание сабжа, то сейчас не очень.

 

Забавно читать посты о системе ивентов, когда имеешь с ней дело каждый день, только на js. Попробуйте отследить, кто слушает конкретный ивент и что то портит в каком нибудь store, хрен что найдешь!

 

- Эй, вы о каких ништяках ваще?

Ништяки? Изменено 4 Февраля 2015 пользователем Desertir

[Murarius 10 533]

 

 

У мине вопрос, об чем спор уже сейчас?

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

[xStream 86]

@Murarius, да не. Тут уже разговор иссяк.

Краткий пересказ:

- тут зырьте крутая штука

- ты че за ересь принес?

- нормально, не то, что раньше фуфло делали!

- эй, мне стыдно, но как умели. Но есть ништяки!

- Ну и нафига нужны эти ништяки? Мои круче.

- не, ну ты не прав, это полезняк!

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

- не, нифига! Макароны не надо, надо ништяки!

- хм... и правда, ниче так ништяки.

- не, ну смотрите, ништяки ваши легко сломать!

- ну вот вам способ залатать.

- хм, и правда. Ну ок, норм ништяки.

- Эй, вы о каких ништяках ваще?

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

[Murarius 10 533]

То есть, докурили то, что было?

"Ну, будет еще - заходи" (с)

[Malandrinus 615]

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

 

Рассмотри это с другой стороны. Толпа модулей подписалась каждый на своё событие: дроп аптечки, дроп спальника, дроп артефакта и т.д. Дроп спальника (не просто дроп) - это событие, адресованное вполне конкретному обработчику. Остальным оно не интересно. Если же событие "дроп такого-то объекта" вдруг интересно не одному, а нескольким обработчикам, то у них должно быть соглашение о взаимодействии, которое включает неудаление объекта.

 

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

 

Поделюсь сразу идеей оптимизации системы событий, прямо противоречащей явному заданию очередности. Допустим, у нас есть некое событие и цепочка обработчиков. Допустим также, что какие-то из них иногда на себе завершают цепочку срабатываний. Допустим также, что это всё происходит довольно часто. Ну скажем что-то там создаётся/удаляется в инвентаре или мы нажимаем часто какие-то сочетания клавиш и т.д. Что имеем. Есть некий список обработчиков и они при вызове все срабатывают в некой очерёдности. Было бы оптимально, чтобы как можно чаще тот обработчик, что заканчивает на себе цепочку, стоял бы ближе к началу очереди (в идеале самым первым). Как это сделать? Можно было бы ввести у каждого обработчика счётчик, считать количество вызовов в случае завершения цепочки на этом обработчике. Ну и сортировать пузырьком по количеству таких прерываний, т.е. просто переставлять местами соседние, сдвигая наиболее часто прерывающий в начало очереди. Тогда можно сэкономить на времени вызова и соответствующих проверок в остальных обработчиках, тех, что стоят позже по очереди.

 

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

 

 

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

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

 

Конечно делали также отладочную систему и для прямых вызовов. Расставляли маркеры-счётчики между такими вызовами, потом ловили момент, когда он не нулевой и по номеру определяли какой из вызовов подвис. Но с сигналами и этого не надо делать, поскольку это автоматически делается для каждого вызова.

 

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

 

 

Предмета нет - это не повод прекращать информационные действия связанные с ним.

Мне одному это утверждение представляется из области некромантии?

[Карлан 1 049]

 

 

Мне одному это утверждение представляется из области некромантии?

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

[Desertir 202]

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

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

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

---

@xStream, я не сомневаюсь. Изменено 5 Февраля 2015 пользователем Desertir

[xStream 86]

@Desertir, ExtJS - просто надстройка над jQuery, а там довольно просто это сделать. Там тот же стек. 

[Desertir 202]

Тут есть весьма интересные задачи. RSA я кстати писал с год назад на байтах. В комментах есть ссылка на простые задачи. Мне особо понравились задачи из раздела Некоторые алгоритмы. Давно хотел свой компилятор написать

[Zander_driver 10 333]

Толпа модулей подписалась каждый на своё событие: дроп аптечки, дроп спальника, дроп артефакта и т.д. Дроп спальника (не просто дроп) - это событие, адресованное вполне конкретному обработчику. Остальным оно не интересно.

т.е. "толпа модулей" в вашем понимании это ВОТ ЭТО?

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

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

И если отбросить всякую мишуру, то у вас получается структура типа такой:

if obj:section() == "matras" then
    ...
end
if obj:section() == "medkit" then
    ...
end
if obj:section() == "bandage" then
    ...
end

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

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

 

Ну неужели так сложно сделать хотя бы так

_g.script

item_reactions = {
    matras = function(obj)
    
    end,
    medkit = function(obj)
    
    end,
    bandage = function(obj)
    
    end
    ...
}

колбек на дроп или где там у вас производят это дело ивенты

if obj and obj:section() and item_reactions[obj:section()] then
item_reactions[obj:section()](obj)
end

И все. Ну хватит уже if-then-else-маразмом заниматься в самом деле.

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

[Карлан 1 049]

@Zander_driver, ну собственно их мало кто городит. Да и опять же лично я не вижу таких страшностей в if-then...end. Ну хотя в последнее время все эти самые if-then...end упраздняю, и заменяю допустим блок строк в 15-20 на одну строку (люблю компактность). Ну и до твоего примера можно докопаться, но все же да, тут я с тобой согласен что так проще (да и лучше) делать. Но вот то что ты привел, писать в _g - кощунство по моему.

 

Но повсеместно вырезать это... Конечно лучше будет, но опять же приходим к польза рефакторинга/затраченное время.

 

 

 

олбек на дроп или где там у вас производят это дело ивенты

Пффф, а не судьба сразу в коллбеке это проверить? Обязательно везде городить?

 

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

[Malandrinus 615]

@Zander_driver,

Я не вижу трагедии в том, что используется так, как используется. Даже в таком виде система ивентов приносит немалую пользу. Но раз уж ты заговорил об этом, то конечно можно и оптимизировать. Вот есть событие дропа, а мы значит хотим сделать более детальное событие "дроп предмета конкретного типа". Это несложно сделать. Когда идёт вызов события, то в качестве идентификатора события указывается строка, "on_drop" к примеру. В качестве модификации напрашивается такой подход:

 

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

Аналогично в системе Анны:

 

event("actor_item_drop_"..obj:section()):trigger({what = obj})

-- в модуле
function init()
    event("actor_item_drop_medkit"):register(on_medkit_drop)
end

function on_medkit_drop(e)
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-и кг

и т.д. Пока не могу сходу сформулировать точный критерий, где надо остановится, но мне видится, что где-то надо.

[Dennis_Chikin 3 658]

Не понимаю... Вроде, все расписывал, примеры давал...

local t = on_drop_t[item:section()]

if t then

for i = 1, #t do t( item ) end

end

- вот и вся "черная магия". Можно вложить внуть каждого t() такое же по любому другому условию. По вкусу вместо t() - if t() ... end (да хоть бы и return).

 

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

 

Upd: Опередили...

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