Перейти к контенту

xStream

 Ветераны
  • Число публикаций

    375
  • Регистрация

  • Последнее посещение

  • Дней в топе

    1
  • AMKoin

    17 [Подарить AMKoin]

Весь контент пользователя xStream

  1. xStream

    Скриптование

    Наглядный пример ООП ради ООП... в реализации без архитектуры :-)
  2. Ну, что я могу сказать... Это как раз тот подход, когда люди делают велосипеды Но дело барское. После такого, даже и искать варианты то решение проблемы не хочется. (той, что ты обозначил) Скажу по секрету - это венгерка И что значит "общепринятые"? Я умоляю, пруф в студию. Как минимум к любому языку существует огромное количество code guideline'ов. Быстрее получить решение такое, которое если что, потом можно "проапгрейдить". У меня вот такой критерий. Эм... ну вроде как написали уже: нет "правильного", есть различные подходы. Я предлагаю, чтобы вью содержала в себе весь функционал, который бы настраивался. Как, в принципе, ты и хотел делать.
  3. Это ужасно... А что мешает использовать тот класс, объектом которого является location? Не придется ничего присваивать. Фиг с ней, с венгеркой, но почему, блин, координаты раздельно то? "Более лучше" © Как эффективнее, так и лучше. Правильно - не то слово, в данном случае.
  4. Саш, ты серьезно? О_о Имхо это вообще не так делается: запоминаем ид того, кто должен перейти, и на переход вешаем колбек. Как только перешел в онлайн, выполняем нужное нам таинство. Это не взятие позиций через диалог, а обновление при смене положения юзера, но принцип тот же. Жирным выделила собственно ключевые места. Я не знаю, как под андроид, но думаю, не сильно отлично отличается от iOS или Веб: вьюха отдельно, логика отдельно. Вьюха включает в себя все элементы, а используют вьюху разные модели/вьюконтроллеры и кастомайзят под себя. Сам функционал получения может быть реализован и во вьюхе и где-то вне ее. Получается примерно так: структура положения - хранит координаты некий сервисный класс, который либо получает положение текущее, либо возвращает значение из списка контроллер диалога - показывает вьюху и кастомайзит ее вьюха имеет логику обращения к сервису и просит получить координаты у него Ну, верно, да Просто к положениям это не относится, как и к получению этих положений. И да, не надо плодить разные классы для вьюх.
  5. Оба варианта не очень. Обычно делают массив положений. А само положение - структура, которая содержит все необходимые характеристики. А вообще, это уже вопрос архитектуры и проектирования. Само по себе количество классов не имеет значения, пока это приносит удобство, простоту и эффективность. Достаточно вспомнить, например, шаблоны в с++ - это же вообще инкубатор классов
  6. @Andrey07071977, ты не то дал, это инструкция по тому, как делать паблик файлы :-)
  7. Понимат, обнимат. Учитывая, что в этом конкретном исполнении - ооп прототипный, это не имеет никакой особой разницы. Мою песочницу можно тоже сделать в нескольких экземплярах, а при небольшой модификации и в полноценный класс превратить. В iOSразработке сталкивалась с тем, что есть несколько notification manager'ов, но все (программисты) используют только DefaultNotificationCenter Имхо, по понятным причинам - это довольно таки избыточно, да и смысл появляется только в мультипоточных приложениях. Возвращаясь к вопросу: зато объект-событие можно передать куда-то, вплоть до того, что внутрь другого события.
  8. У меня так вообще класс-обертка, который инкапсулирует все взаимодействие с подобным менеджером. Вопрос привычки, стиля и удобства.
  9. Честно говоря, я вообще не понимаю, что ты хочешь. Loadstring вернет результат выполнения строки (как скрипта) и возникнет сигнал с именем-результатом. Но что-то у тебя уже сработало, то есть по сути ты замену сделал самой системе событий - одна единственная функция с ветвлением. А сигналы тут вообще никаким боком.
  10. xStream

    C++

    @Desertir, темплейты всегда в заголовках потому, что у них нет непосредственно кода реализации: классы (функции) создаются по мере надобности. Точнее, шаблон можно вынести в cpp, но это описание никто нигде не увидит, так как подключаются хедеры, а не файлы имплементации. Смутно помню, что в какой-то из новых версий то ли языка, то ли студии, можно определять шаблон в .cpp Ответ на твой вопрос: описание шаблона вместе с реализацией должно быть в зоне видимости всех тех мест, где ты это используешь - это делают в заголовочных файлах.
  11. --тут был абсурд про хешмап, позор на мои седины-- А для чего тогда, если оно никаких преимуществ не даст? Хардкод даст, макаронный код даст, эффективность не даст. Профит в чем?
  12. На минуточку: в луа конструкция t[obj:section()] и набор колбеков со стоками типа if obj:section() == 'fuck_the_millenium" return end внутри выполнятся одинаково. Именно потому, что получение значения по ключу - тот же перебор, по хешмапу. А тут перебор колбеков до первого подходящего - та же табличка и то же сравнение. Разница только в дополнительном микросекундном вызове одной функции. Вообще, знаете как работают конструкции типа t ?
  13. @Desertir, ExtJS - просто надстройка над jQuery, а там довольно просто это сделать. Там тот же стек.
  14. @Murarius, да не. Тут уже разговор иссяк. Краткий пересказ: - тут зырьте крутая штука - ты че за ересь принес? - нормально, не то, что раньше фуфло делали! - эй, мне стыдно, но как умели. Но есть ништяки! - Ну и нафига нужны эти ништяки? Мои круче. - не, ну ты не прав, это полезняк! - о, ребя, чего это вы тут творите? Не ссорьтесь, все ништяки одинаково полезны. - не, нифига! Макароны не надо, надо ништяки! - хм... и правда, ниче так ништяки. - не, ну смотрите, ништяки ваши легко сломать! - ну вот вам способ залатать. - хм, и правда. Ну ок, норм ништяки. - Эй, вы о каких ништяках ваще?
  15. Правда, что ли? :-) Рефакторить микросекундные вызовы? Заниматься копипастой? Нененедевидблейн Да тащемто нет. Подписываются только те, кому надо. И от подобных переборов ты никуда не уйдешь. Главный цимес, что можно это делать динамически (и вот такие реальные случаи были у меня) это, кстати, что такое?
  16. , нифига. Это просто удобно. Для себя тем более, выше даже примеры приводились. Изоляция и локализация важных мест - это круто, удобно и эффективно.
  17. Это объекты с разными секциями. Собственно все И все перечисленное тоже легко разносится по какому-либо признаку.
  18. Попробую пояснить мысль, как на мой взгляд стоит сделать: когда подписчик отработал с объектом, он должен просто просигналить в систему (need_delete), что мол этому предмету нужен кирдык и лучше с ним ваще не работать. есть модуль, который отрабатывает это need_delete - и он единственный. И уж решает, что там дальше делать с этим неудачником по жизни. В общем, способов много разных в пределах одной концепции. Но я все же не могу представить реальной ситуации, когда два подписчика могут абстрактно обрабатывать on_drop "просто так": обычно обрабатываются предметы конкретных типов и только одним модулем, больше никакими. Ну то есть теоретически могу и для этого есть варианты решения, но вот практически. Просто семантически on_drop должен обрабатывать выпадение предмета и все. А уж провоцировать удаление должно что-то другое. Отложенная логика или еще что-нибудь, не знаю... фейковый пакет как и любой объект в ЛУА существует до тех пор, пока на него ссылаются, как только перестали - он попадает в сборщик мусора. То бишь, вполне может быть так, что ивент запускать не с самим объектом, а оберткой, а у него уже, у объекта этого какие-то свойства, которые будут отрабатывать в месте бросания колбека после отработки стека. да вот даже сами ивенты в моей песочнице - суть наглядный пример таких объектов: создаются, отправляются колбекам, и на свалку. А еще им можно присваивать свойства и вызывать методы, которые после стека отрабатываются уже в ядре песочницы.
  19. Потому что это ошибка проектирования системы в принципе. Ты пишешь код, ты используешь инструмент - ну что тебе мешает расставить приоритеты, например, или сделать так, чтоб предмет вообще не должен был удаляться, а только помечаться на удаление? Это самый безопасный способ, раз уж на то пошло, не зависимо от того, адресное событие или широковещательное. Но мне он не нравится, я бы постаралась спроектировать, чтобы до таких вещей не доходило. Подобные вещи мне как раз очень напоминают истории с итерациями по массиву при удалении элементов из этого массива. В общем то, это кривизна реализации движка, а не системы событий. Кстати, в догонку: пример того, как я вижу решение подобных проблем - фейковый нетпакет в моей библиотеке для работы с ними (с нетпакетами). Он предоставляет точно такой же интерфейс, как и все остальные, но просто ничего не делает.
  20. При чем тут апдейты вообще?
  21. Иногда полезно. В общем случае это так и работает, как там написано. Во-первых, проверять не надо - второй не будет вызван. Во-вторых, можно использовать подход разделения "безопасных" и "небезопасных" колбеков (в случае, если лебедятам не надо удалять объект, можно на on_item_drop_safe подписать). В-третьих, do_swan_dance и on_drop - разные события: внутри on_drop сказать - станцуйте (без удаления), а потом удалить. В-четвертых, можно кидать всякие item_will_be_removed или on_release - и подписать любителя лебедей на оба события - on_drop и on_release. В-пятых - можно таки указать приоритет, если песочница позволяет (но я бы не рекомендовала, не хорошо это) В-шестых, если уж реально припрет всех пробежать, а удалить после колбека - можно сделать опять же дополнительный тип сообщения. К примеру, он смотрит объект, прошедший через цепочку вызовов, и проверяет наличие свойства need_release. И тогда киается удаление. Но вот послединй пункт отдает поганым извратом и костылями. По хорошему в игровой ситуации практически не бывает пересечения интересов. Естественно, просто принять соглашение, что в таком ивенте трогать "посылку" нельзя.
  22. Хорошо, вот вам еще решение в лоб: создавать два сообщения on_item_drop_safe и on_item_drop. safe кидается перед обычным. Подписчики на safe гарантируют сохранность "объекта доставки". Это своеобразный аналог const функций в том же C++, например. Просто в ЛУА такого нет.
  23. Потому что это семантически суть разные вещи. А on_release будет обрабатывать другой стек колбеков, возможно совсем маленький. Главное, что такой ивент можно кинуть до непосредственно удаления, как только все "дочерние" колбеки отработают - сносим объект и стопаем текущий. Никаких проблем. По аналогии могу привести вязыках программирования так называемые rethow исключений - принцип тот же: поймали бяку, отработали и кинули новый эксепшн, который всплывает дальше.
  24. , ммм. Что-то я потеряла нить размышлений.Я говорила не конкретно об item_drop, а каких-то других вещах - например скриптом сделали удаление (не внутри какого-либо колбека), имитируем дроп, стартанув ивент вручную. Видимо, мой полет мысли слишком стремительно увел ее, мысль, далеко от конкретного примера
  25. Этому новому-новому сто лет в обед. Я выдавала на гора свою песочницу в еще 2012 году, кажется, Саша тогда же слоты выдал. (Да и куча других вещей датируется теми временами) Это тут разговор вылился из темы рефакторинга: не надо исправлять макаронный код, а надо использовать более эффективные вещи.

AMK-Team.ru

×
×
  • Создать...