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

[Dennis_Chikin 3 658]

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

 

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

 

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

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

[Desertir 202]

и проверяет наличие свойства need_release

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

[Dennis_Chikin 3 658]

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

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

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

[xStream 86]

 

 

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

При чем тут апдейты вообще? 

[Dennis_Chikin 3 658]

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

[Malandrinus 615]

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

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

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

Вести коллекции предметов - плохая идея по многим причинам. Например потому, что вообще желательно не запоминать предметы между скриптовыми вызовами. Удаление движкового объекта не ведёт к автоматическому удалению его скриптовой оболочки. Другой скрипт может удалить предмет из коллекции, и мы получим скриптовую оболочку с мёртвым указателем внутри. Кроме того сама постановка вопроса: "что если в коллекции будут предметы, которые другой колбек удалит?" уже означает заведомые проблемы с управлением разделяемыми ресурсами. Я должен исключить такую ситуацию на уровне дизайна.

Мысль о том, что "все должны получить сообщение" тоже неверна. Сообщения могут быть и широковещательные, но вообще-то они как правило адресные и предназначены конкретному адресату. Здесь нет никакой дилеммы. Если сообщение по сути адресное, то оно и должно закончиться на его адресате. Остальным оно не предназначено. Если же сообщение широковещательное, то вряд ли один из адресатов будет заниматься безобразиями с данными, предназначенными всем. Если же будет, к примеру будет удалять объект, предназначенный всем, то это не проблема системы ивентов, а проблема либо дизайна либо исполнения моей системы. Это и надо лечить.

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

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

[Dennis_Chikin 3 658]

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

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

 

Тоже возвращусь к началу - просто стоит запомнить, что это - возможно, и не ломать.

Если попытка поломать где-то замечена - убрать.

(на самом деле вопрос такой был: "откуда может взяться клиентский объект без серверного". Как выяснили - может.)

 

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

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

[Zander_driver 10 334]

 

 

С какой стати? Если предмет удалён, то потерян смысл доставлять сообщение дальше. Ещё раз хочу подчеркнуть. Огрызок объекта в виде его онлайновой части - это не повод думать, что объект ещё существует. Его уже нет, а значит нечего дальше передавать. Рассмотри это с такой точки зрения. Событие с объектом - это нечто вроде доставки почты. Мы идём по комнатам и спрашиваем "это для тебя?" Как нашли адресата, то отдали ему предмет. На этом всё, дальше доставлять нечего и некому.

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

 

 

Хорошо, вот вам еще решение в лоб: создавать два сообщения on_item_drop_safe и on_item_drop. safe кидается перед обычным. Подписчики на safe гарантируют сохранность "объекта доставки". Это своеобразный аналог const функций в том же C++, например. Просто в ЛУА такого нет.

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

[Карлан 1 049]

 

 

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

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

[Zander_driver 10 334]

Дочитал блин. malandrinus, как мне кажется, все время имеет в виду нечто чуть другое нежели остальные.

1.Мысль, как уже говорил но повторюсь. Если кто-то сотворил безобразие с объектом, то вот ни в коем разе это не значит что остальным надо рубить вызовы. Почем вам знать, что эти остальные хотели делать. у вас рассуждения будто они все поголовно искали повода объект удалить, аки волки какие.

2. Порочная практика, рассадники феерических багов... ну для начала рассадник феерических багов это хранение "откуда-то" "как-то" полученной юзердаты клиентского объекта, и последующие попытки над ней что-то сделать. Вот это и искоренять лютым образом.
3. Как уже озвучено xStream, немножко дожую. Как у себя реализовал в _кое-чем_ : есть разделение на действие информационное, и действие - действенное. т.е.

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

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

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

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

[Карлан 1 049]

 

 

я к примеру заранее не имею понятия о числе модулей

Это уже что-то из области фантастики... Интересно как я не могу знать число модулей, если сам же их подключаю? Конкретно если говорить за ивенты, там идет учет количества например, и тут уже дело за расставлением приоритетов, а не какой-то телепатией.

 

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

[Zander_driver 10 334]

 

 

Но все же лучше приоритеты, да.

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

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

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

 

 

Для "информационного" действия всего-то нужно послать "куда требуется"

Вот этот пост говорит о чем-нибудь?

[Карлан 1 049]

 

 

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

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

 

 

 

Вот этот пост говорит о чем-нибудь?

Немного ниже него можешь увидеть, о чем он мне говорит.

[Zander_driver 10 334]

 

 

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

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

Но вообще да. В свете таких событий актуальность дальнейшей дискуссии ниже нуля.

[Andrey07071977 18]

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

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

[Zander_driver 10 334]

 

 

Zander_Driver, помоему ты просто не до конца понимаешь о чем здесь толкуют

Очень может быть что так и есть. Но местами у меня бывает ощущение ровно наоборот. Касательно того поста xStream - понравилось потому что местами сам так и делаю. А почему так делать не надо - не понимаю.

[Dennis_Chikin 3 658]

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

А вот то, что топор каменный и пила кривая (и еще в нее надо бензин заливать) - по назначению применять не пробовали, нет ? Прежде чем переходить на "да я, да ты..." ?

 

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

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

[RayTwitty 508]

Уже 5 лет использую прямые вызовы из пысовских модулей в свои и бед не знаю. Да и, для меня не проблема поставить проверку if obj then. Плюс сразу видно куда и что вызывается, не надо юзать коммандер для поиска подключений и потом скороллить вниз огромного модуля и смотреть какие колбеки тут есть.

 

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

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

[xStream 86]

 

 

А почему так делать не надо - не понимаю.

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

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

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

В общем то, это кривизна реализации движка, а не системы событий.

Кстати, в догонку: пример того, как я вижу решение подобных проблем - фейковый нетпакет в моей библиотеке для работы с ними (с нетпакетами). Он предоставляет точно такой же интерфейс, как и все остальные, но просто ничего не делает.

[Nazgool 250]

как я вижу решение подобных проблем - фейковый нетпакет

Да, такое решение и напрашивается.

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

Ведь неизвестно сколько еще модулей, использующих этот объект, могут быть подключены в будущем.

Объектов же больше чем много. Не хранить же их все в фейках.

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

[xStream 86]

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

когда подписчик отработал с объектом, он должен просто просигналить в систему (need_delete), что мол этому предмету нужен кирдык и лучше с ним ваще не работать.

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

В общем, способов много разных в пределах одной концепции.

Но я все же не могу представить реальной ситуации, когда два подписчика могут абстрактно обрабатывать on_drop "просто так": обычно обрабатываются предметы конкретных типов и только одним модулем, больше никакими.

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

 

 

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

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

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