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

[Dennis_Chikin 3 658]

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

 

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

 

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

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

[Malandrinus 615]

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

 

Нет, это я просто не до конца цитирую код. self.sm - это ссылка на глобальный менеджер событий, которую я сохранил ранее для экономии.

self.sm = ogse_signals.get_mgr()

для того, чтобы каждый раз не писать полный вызов, который выглядел бы так:

ogse_signals.get_mgr():call("on_drop", obj)

 

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

[Andrey07071977 18]

@Malandrinus, а в чем преимущество сохранять менеджер в обьекте а не просто в начале файла? i.e.:

local sm = ogse_signals.get_mrg()

[Malandrinus 615]

@Andrey07071977, Общее правило: чем локальнее данные, тем лучше. Чаще всего это лучше с точки зрения ограничения видимости, дабы уменьшить вероятность конфликтов. В случае Lua ещё и быстрее работает.

PS: на самом деле в данном случае нет особой разницы, просто я уже рефлекторно следую этим правилам.

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

[xStream 86]

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

[Nazgool 250]

 

 

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

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

А так менеджер всегда под рукой в поле sm.

[Andrey07071977 18]

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

 

P.S> ты свой Syntax Checker не обновлял с 2012? Конкретно интересует возможность использования стороннего lua.dll

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

[Desertir 202]

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

[Malandrinus 615]

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

 

Поскольку я повёрнут на ООП, то я исходно сделал менеджер сигналов как класс, а не модуль. Таким образом, можно завести несколько объектов такого класса =) Помнится, была идея использовать отдельный экземпляр менеджера событий для системы управления лампочками. Дело в том, что там я активно использовал очерёдность выполнения АКА низкоприоритетные апдейты (их тут называли поллингом, но по-моему не совсем подходит под определение). Смысл использования отдельного менеджера событий был в том, чтобы  изолировать очереди из десятков лампочек от остальных очерёдных событий. Но потом отказался от этой мысли и все лампочки навесил на глобальный менеджер. Задержка срабатывания получилась практически незаметная.

 

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

 

function attach(sm)
    sm:subscribe({signal = "on_update", fun = this.on_update_low_priority, queued = true})
end

function on_update_low_priority()
end

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

 

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

 

 

[Andrey07071977 18]

@Malandrinus, к твоему посту быше - я так и не нашел применения для низкоприоритетных, и в итоге заменил на временные, так сказать. Вкратце, вместо queued = true, будет interval = XXX в микросекундах, а в менеджере проверяю разницу разницу по времени и если нужно исполняю функию.

[Malandrinus 615]

 

 

не могу не дать эту ссылку

На мой взгляд, автор данной статьи попросту оправдывает свою лень, призывая в помощь Силу Самодокументированного Кода. Как там Аня сказала? "он не мифический, но недостижимый". Признаться, не хочется спорить с этим перцем. Я просто предлагаю поглубже познакомиться с исходниками x-ray. Там неплохой код в смысле самодокументации. Адекватные названия переменных и функций, отформатировано... Желаю удачи с разбором. Понадобится.

 

 

не нашел применения для низкоприоритетных

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

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

[Desertir 202]

@Malandrinus, оставим код XRay на совести разрабов. Для меня важен мой код, а разбор в чужом без нормальных доков/комментов это другая история.

Кстати, про очерёдные события уже писал @Dennis_Chikin. Правда я тогда начал спорить о том, что если будет "долгая" функция, то неважно, будет она выполнена вместе с другими или же одна на одном апдейте. Но размытие по апдейтам было есть и будет, думаю, главное правильно применять.

[xStream 86]

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

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

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

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

[Andrey07071977 18]

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

 

Вот. По моему это последняя версия что я делал, буду рад если покритикуешь 

 

P.S> спасибо @xStream, исправил

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

[xStream 86]

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

[Dennis_Chikin 3 658]

"Но секунды - это уже совсем экстрим" - иногда бывает как раз полезно. Скажем, событие происходит раз в час, с точностью +- полчаса. Ну или даже пусть бы и раз в 5 секунд. Зачем здесь нужен лютый, бешеный поллинг с максимальной скоростью ?

 

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

[Nazgool 250]

 

 

Конкретно интересует возможность использования стороннего lua.dll

В смысле lua5.1.dll ?

Программу (UI) запускает wlua.exe для версии lua 5.1, которая линкуется с либой lua5.1.dll. Вот их и нужно "подружить".

[Viнt@rь 50]

Пишу на Java(Android), и хотел бы уточнить кое что, есть некий класс диалогового окна, унаследованный от базового DialogFragment, в диалоге выполняется смена какого-то значения пользователем, допустим - выбор местоположения из предоставленного списка, с помощью этого диалога, пользователь может выбрать свое текущее местоположение, и конечный адрес, соответственно "запоминать" координаты и сам адрес нужно в разные переменные, в итоге в голову пришло такое, да бы не плодить классов разных, задавать какой то там булеан типа isFinalAddress при создании/открытии диалога и повсюду, где нужно, смотреть, выставляем конечный адрес или нет, ну и при этом выполнять нужные действия... 

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

С точки зрения ООП, я так понимаю, что более правильный - второй вариант, но в итоге у нас на 1 класс(ну и естественно файл) становиться больше, мне то это не принципиально, но все же...

Таких моментов(классов) в приложении примерно 3-4, то есть в итоге, если действовать по второму варианту, то кол-во классов увеличиться еще на такое же число.

[xStream 86]

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

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

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

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

[Viнt@rь 50]

Обычно делают массив положений.

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

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

 

В случае с первым вариантом реализации такого(таких диалогов) код будет выглядеть в таком плане:

...
if (isFinalAddress) {
    button.setVisibility(View.GONE);
}
...

Изменено 7 Февраля 2015 пользователем Viнt@rь

[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