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

[xStream 86]

 

Э... Да, что-то полет мысли... случился, да.

Иногда полезно. В общем случае это так и работает, как там написано.

 

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

Во-первых, проверять не надо - второй не будет вызван.

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

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

В-четвертых, можно кидать всякие item_will_be_removed или on_release - и подписать любителя лебедей на оба события - on_drop и on_release.

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

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

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

По хорошему в игровой ситуации практически не бывает пересечения интересов.

 

 

Это должен гарантировать скриптер

Естественно, просто принять соглашение, что в таком ивенте трогать "посылку" нельзя.

[xStream 86]

 

 

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

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

[xStream 86]

 

 

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

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

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

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

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

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

[xStream 86]

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

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

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

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

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

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

 

 

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

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

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

[xStream 86]

 

 

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

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

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

[xStream 86]

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

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

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

[xStream 86]

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

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

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

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

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

мегасистем

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

[xStream 86]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[xStream 86]

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

[xStream 86]

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

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

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

[xStream 86]

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

 

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

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

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

[xStream 86]

 

 

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

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

[xStream 86]

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

[xStream 86]

Поскольку я повёрнут на ООП

Понимат, обнимат. Учитывая, что в этом конкретном исполнении - ооп прототипный, это не имеет никакой особой разницы. Мою песочницу можно тоже сделать в нескольких экземплярах, а при небольшой модификации и в полноценный класс превратить. В iOSразработке сталкивалась с тем, что есть несколько notification manager'ов, но все (программисты) используют только DefaultNotificationCenter Имхо, по понятным причинам - это довольно таки избыточно, да и смысл появляется только в мультипоточных приложениях.

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

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

[xStream 86]

@Andrey07071977, ты не то дал, это инструкция по тому, как делать паблик файлы :-)

[xStream 86]

С точки зрения ООП, я так понимаю, что более правильный

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

А вообще, это уже вопрос архитектуры и проектирования. Само по себе количество классов не имеет значения, пока это приносит удобство, простоту и эффективность. Достаточно вспомнить, например, шаблоны в с++ - это же вообще инкубатор классов

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

[xStream 86]

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

 

 

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

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

Хотелось бы пример увидеть, если не сложно

 

 

// Delegate method from the CLLocationManagerDelegate protocol.
- (void)locationManager:(CLLocationManager *)manager
      didUpdateLocations:[b](NSArray *)locations[/b] {
    // If it's a relatively recent event, turn off updates to save power.
  [b] CLLocation* location = [locations lastObject];[/b]
   NSDate* eventDate = location.timestamp;
   NSTimeInterval howRecent = [eventDate timeIntervalSinceNow];
   if (abs(howRecent) < 15.0) {
      // If the event is recent, do something with it.
      NSLog(@"latitude %+.6f, longitude %+.6f\n",
              location.coordinate.latitude,
              location.coordinate.longitude);
   }
}

 

 

Это не взятие позиций через диалог, а обновление при смене положения юзера, но принцип тот же. Жирным выделила собственно ключевые места.

 

 

И да, забыл упомянуть, помимо логики, еще диалоги немного разные в визуальном плане, почему немного?

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

Получается примерно так:

структура положения - хранит координаты

некий сервисный класс, который либо получает положение текущее, либо возвращает значение из списка

контроллер диалога - показывает вьюху и кастомайзит ее

вьюха имеет логику обращения к сервису и просит получить координаты у него

 

 

код будет выглядеть примерно так:

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

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

[xStream 86]

Отсюда по всему классу диалога будет код такого вида:

Это ужасно...

 

Вот выше приведенное в пример, показалось мне костылем

А что мешает использовать тот класс, объектом которого является location? Не придется ничего присваивать. 

 

mSettings.setCurLatitude(loc.getLatitude()); 
mSettings.setCurLongitude(loc.getLongitude())

Фиг с ней, с венгеркой, но почему, блин, координаты раздельно то?

 

 

Вопрос вообще заключается не в том, как это сделать, а какой подход более правильный!

"Более лучше" © Как эффективнее, так и лучше. Правильно - не то слово, в данном случае.

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

[xStream 86]

пусть и на несколько байт, но все же

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

 

 

Это не венгерка,

Скажу по секрету - это венгерка И что значит "общепринятые"? Я умоляю, пруф в студию. Как минимум к любому языку существует огромное количество code guideline'ов.

 

 

А критерий эффективности какой?

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

 

 

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

Эм... ну вроде как написали уже: нет "правильного", есть различные подходы. Я предлагаю, чтобы вью содержала в себе весь функционал, который бы настраивался. Как, в принципе, ты и хотел делать. Изменено 7 Февраля 2015 пользователем xStream