SObjectizer 5.3.0

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

SObjectizer обновился до версии 5.5.9. Вкратце изменения таковы:

• возможность использовать произвольные типы в качестве типов сообщение (наследование от message_t больше не обязательно, но тип должен быть MoveConstructible);
  
• класс wrapped_env_t, позволяющий работать с SObjectizer Environment в более привычном для ООП стиле;
  
• возможность трассировки механизма доставки сообщения (для упрощения отладки SObjectizer-приложений и поиска ошибок, связанных с подписками и отсылкой сообщений не тем получателям);
  
• новые функции request_value и request_future для упрощения синхронного взаимодействия агентов;
  
• несколько новых вариантов функции send, позволяющие использовать send вместо send_to_agent (что удобно при обобщенном программировании);
  
• исправлено несколько ошибок, добавлена пара новых примеров.

Чуть подробнее об изменениях рассказывается в этой презентации или в этом посте. Полный список изменений можно найти в Wiki.

Так же сделаны две новые презентации, которые коротко рассказывают о таких возможностях SO-5.5, как синхронное взаимодействие агентов и лимиты для сообщений.

Версию 5.5.9 можно взять либо из секции Files на SF, либо из Svn-репозитория, либо из зеркала на GitHub (на GitHub-е теперь git submodules не используется, так что самую последнюю версию можно просто скачать с GitHub-а в виде архива и в ней сразу будут все необходимые подпроекты).

В обсуждениях SO-5 часто упоминалось, что у нас не удобный/понятный API. Есть желание сделать его удобнее и понятнее. Например, вот такой шаг был бы шагом в верном направлении?

Цитата eao197 @ 27.11.15, 08:26

Например, вот такой шаг был бы шагом в верном направлении?

Возможно вам удобнее, но, имхо, количество подчеркиваний в вашем коде зашкаливает за 9000! Не скажу за всех, скажу за себя, наличие подчеркиваний в "публичных интерфейсах" библиотеки меня приводит в уныние. Не знаю. Возможно дело привычки. Стереотипы ломать сложно. Это наверное самое первое, но, как говорят "встречают по одежке".

Второе. "Шапка" темы ужасная и неструктурированная. Уберите нафик детали!

* описание
* возможности
* области применения
* работающие примеры использования
* глоссарий и "расшифровка" деталей под сполйлерах

Остальное все нафик, ибо пофик! Меньше слов, больше конкретики и обобщений.
Чисто мое ИМХО, без обид.

Цитата JoeUser @ 27.11.15, 16:44

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

Э... Ну вот возьмем произвольный пример:

namespace props = so_5::rt::mchain_props;
so_5::rt::mchain_params{
     props::capacity::make_limited_without_waiting(
          5,
          props::storage_memory::dynamic,
          props::overflow_reaction::drop_newest ) }

Как бы вы уменьшили количество подчеркиваний в нем?

Цитата JoeUser @ 27.11.15, 16:44

Второе. "Шапка" темы ужасная и неструктурированная. Уберите нафик детали!

На счет "шапки" темы не понял. Речь по самое первое сообщение в теме?

Сообщение отредактировано: eao197 - 27.11.15, 16:54

Цитата eao197 @ 27.11.15, 16:53

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

Мне бы так читалось в 7,4 раза бы приятнее:

    namespace Props = Olib::Rt::MChainProps;
    Olib::Rt::MChainParams{
         Props::Capacity::MakeLimitedWithoutWaiting(
              5,
              Props::StorageMemory::Dynamic,
              Props::OverflowReaction::DropNewest ) }

Цитата eao197 @ 27.11.15, 16:53

На счет "шапки" темы не понял. Речь по самое первое сообщение в теме?

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

Цитата eao197 @ 27.11.15, 08:26

Например, вот такой шаг был бы шагом в верном направлении?

Лично я вообще против всяких префиксов/суффиксов, и прочих способов выделения идентификатора.

Добавлено 27.11.15, 17:10

Цитата JoeUser @ 27.11.15, 17:09

Мне бы так читалось в 7,4 раза бы приятнее

Это всё субъективщина. Мне stl-style нравится гораздо больше.

Цитата MyNameIsIgor @ 27.11.15, 17:10

Лично я вообще против всяких префиксов/суффиксов, и прочих способов выделения идентификатора.

Плюсую.

Цитата JoeUser @ 27.11.15, 17:09

Мне бы так читалось в 7,4 раза бы приятнее:

    namespace Props = Olib::Rt::MChainProps;
    Olib::Rt::MChainParams{
         Props::Capacity::MakeLimitedWithoutWaiting(
              5,
              Props::StorageMemory::Dynamic,
              Props::OverflowReaction::DropNewest ) }

Библиотека была написана с использованием snake_case, в C++компьюнити это один из самых распространенных стилей. Перейти на CamelCase означает все переписать. Да и у CamelCase противников даже больше, чем у snake_case. Я сам, например, очень долго использовал CamelCase, но затем отказался от него в пользу snake_case, дабы глаза поберечь.

Цитата MyNameIsIgor @ 27.11.15, 17:10

Это всё субъективщина. Мне stl-style нравится гораздо больше.

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

ЗЫ: За исключением clib, где это возведено в ритуалЪ:)

Цитата JoeUser @ 27.11.15, 17:09

Цитата eao197 @ 27.11.15, 16:53

На счет "шапки" темы не понял. Речь по самое первое сообщение в теме?

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

По согласованию с администрацией форума мы обсуждения всех обновлений SO-5 делаем в той же самой теме, в которой был сделан первый анонс. Поэтому вот такая вот картинка и получается.

Цитата eao197 @ 27.11.15, 17:14

Библиотека была написана с использованием snake_case, в C++компьюнити это один из самых распространенных стилей. Перейти на CamelCase означает все переписать. Да и у CamelCase противников даже больше, чем у snake_case. Я сам, например, очень долго использовал CamelCase, но затем отказался от него в пользу snake_case, дабы глаза поберечь.

Вы меня теряете!!!

Цитата MyNameIsIgor @ 27.11.15, 17:10

Цитата eao197 @ 27.11.15, 08:26

Например, вот такой шаг был бы шагом в верном направлении?

Лично я вообще против всяких префиксов/суффиксов, и прочих способов выделения идентификатора.

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

Добавлено 27.11.15, 17:20

Цитата JoeUser @ 27.11.15, 17:17

Вы меня теряете!!!

Так как же вы стандартной библиотекой C++ пользуетесь? Или Boost-ом?

Цитата eao197 @ 27.11.15, 17:18

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

Это всё субъективно, а не объективно. Потому и заменяться должно по такому же принципу: захотелось - заменили.

Цитата eao197 @ 27.11.15, 17:18

Или Boost-ом?

Я очень уважаю коллег, которые пользуются бустом! Но, к своему стыду, никогда им не пользовался. Использую Qt5 для своих задач. Сперва все было просто фантастически, но, со временем, эйфория ушла. Увы. Возможно тутошнее общение, возможно Oraizer, возможно искривление пространственно-временного континуума, привели меня к мысли, что - кулл это STL, это хорошо и правильно!

Цитата eao197 @ 27.11.15, 17:18

Грубо говоря, определить, скольким людям суффиксы мешают.

Отсебятина. Нафик вложение в переменные смысла! Если_вы_определите_переменную_обладающую_смыслом - легче не будет! Используйте однобуквенный идентификатор + комментарии. Это сократит код и повысит наглядность. ИМХО.