SObjectizer 5.3.0

Цитата Qraizer @ 02.07.14, 17:35

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

Да, собственно говоря, так оно и есть.

Цитата MyNameIsIgor @ 02.07.14, 09:47

Ну, меня интересует не программа с точно такой же семантикой, а просто аналог конструкций

    // a philosopher that receives {eat} stops thinking and becomes hungry
            thinking = (
                on(atom("eat")) >> [=] {
                    become(hungry);
                    send(left, atom("take"), this);
                    send(right, atom("take"), this);
                }
            );
            // wait for the first answer of a chopstick
            hungry = (
                on(atom("taken"), left) >> [=] {
                    become(waiting_for(right));
                },
                on(atom("taken"), right) >> [=] {
                    become(waiting_for(left));
                },
                on<atom("busy"), actor>() >> [=] {
                    become(denied);
                }
            );
            // philosopher was not able to obtain the first chopstick
            denied = (
                on(atom("taken"), arg_match) >> [=](const actor& ptr) {
                    send(ptr, atom("put"), this);
                    send(this, atom("eat"));
                    become(thinking);
                },
                on<atom("busy"), actor>() >> [=] {
                    send(this, atom("eat"));
                    become(thinking);
                }
            );
            // philosopher obtained both chopstick and eats (for five seconds)
            eating = (
                on(atom("think")) >> [=] {
                    send(left, atom("put"), this);
                    send(right, atom("put"), this);
                    delayed_send(this, seconds(5), atom("eat"));
                    aout(this) << name
                               << " puts down his chopsticks and starts to think\n";
                    become(thinking);
                }
            );

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

А вот интересно, если знаете, конечно, как в libcppa при наследовании от какого-то уже имеющегося класса агента модифицировать определение состояния? Вот, например, определил родительский класс в состоянии denied обработчики атомов denied и busy. А потомок хочет заменить обработчик атома busy и добавить обработчик еще одного атома tryagain. Можно это в libcppa сделать?

Цитата eao197 @ 02.07.14, 19:53

А вот интересно, если знаете, конечно, как в libcppa при наследовании от какого-то уже имеющегося класса агента модифицировать определение состояния? Вот, например, определил родительский класс в состоянии denied обработчики атомов denied и busy. А потомок хочет заменить обработчик атома busy и добавить обработчик еще одного атома tryagain. Можно это в libcppa сделать?

Без понятия. Ну, кроме создания своего состояния в потомке и присвоения его состоянию в предке, но это не декомпозиция по обработчикам, да.

Цитата MyNameIsIgor @ 02.07.14, 20:41

Без понятия. Ну, кроме создания своего состояния в потомке и присвоения его состоянию в предке, но это не декомпозиция по обработчикам, да.

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

SObjectizer в этом плане дает больше возможностей разработчику. Подписку на сообщения в конкретном состоянии можно изменить -- отменить старую или добавить новую.

Цитата eao197 @ 02.07.14, 20:46

SObjectizer в этом плане дает больше возможностей разработчику. Подписку на сообщения в конкретном состоянии можно изменить -- отменить старую или добавить новую.

Настораживает. Грозит непонятными проблемами и сильной связностью.

Цитата MyNameIsIgor @ 02.07.14, 20:49

Настораживает. Грозит непонятными проблемами и сильной связностью.

Наследование -- это и так очень сильная связанность.
А реакцию на сообщение можно рассматривать как виртуальный метод. В принципе, в Smalltalk и Ruby это почти так и есть -- вызов метода как отсылка сообщения, обработчик которого может быть переопределен в производном классе.
Соответственно, замена обработчика в производном классе -- вполне нормальна вещь. Как и расширение списка состояний и/или списка обработчиков в конкретном состоянии.

Цитата eao197 @ 02.07.14, 21:08

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

Я в курсе, и подход C++/C# с чётким декларированием точек расширения лучше.

Цитата eao197 @ 02.07.14, 21:08

Соответственно, замена обработчика в производном классе -- вполне нормальна вещь.

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

Цитата MyNameIsIgor @ 02.07.14, 14:26

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

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

Цитата MyNameIsIgor @ 02.07.14, 14:26

Потому что ни assert'ы, ни котракты (в смысле языковых возможностей) не являются формальной верификацией.

Где у меня вообще упоминается формальная верификация??

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

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

Цитата MyNameIsIgor @ 02.07.14, 14:26

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

DbC не имеет никакого отношения к тестированию. Потому что DbC = Design by Contract, это примеяется на ранних стадиях проектирования и затем затрагивает все остальное. А во что выльется в дальнейшем - в fail hard, автоматическую формальную ферификацию, defense programming, ... - это уже совсем другая история.

Цитата bsivko @ 03.07.14, 09:35

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

Мне кажется, что вы путаете математическое описание АТД и его реализацию в виде класса.

Цитата

Переход от АТД к классам включает существенное изменение стилистики: введение изменений и императивных аргументов.

Как вы помните, спецификация абстрактных типов данных не описывает явно изменений, т. е., используя термин из теоретической информатики, является аппликативной. Все свойства АТД моделируются как математические функции, это относится к конструкторам, запросам и командам. Например, операция вталкивания для стеков моделируется функцией-командой:

put: STACK [G] x  G -> STACK [G]

задающей операцию, которая возвращает новый стек, а не изменяет существующий.

Классы отказываются от чисто аппликативной точки зрения на функции и переопределяют команды как операции, которые могут изменять объекты. Например, операция put будет определена как процедура, которая получает некоторый элемент типа G (формальный параметр) и модифицирует стек, вталкивая новый элемент на его вершину, не создавая нового стека.

Такое изменение стиля отражает императивные настроения, преобладающие при разработке ПО. (В качестве синонима слова "императивный" иногда используется термин "операционный"). При этом потребуется изменять аксиомы АТД. Аксиомы стеков A1 и A4, которые имели вид

(A1) item (put (s, x)) = x
(A4) not empty (put (s, x))

превратятся в императивной форме в предложение, называемое постусловием программы (routine postcondition), вводимое ключевым словом ensure (обеспечивает):

put (x: G) is
      -- Втолкнуть x на вершину стека
   require
      ... Предусловие (если таковое имеется) ...
   do
      ... Соответствующая реализация (если известна) ...
   ensure
      item = x
      not empty
   end

Так же можете посмотреть главу книги "Основы объектно-ориентированного программирования" про проектирование по контракту, ту часть, где описано связывание АТД и классов, где рассказано про утверждения, про их отличия от формальной спецификации аксиом и предусловий АТД и пр.

Сообщение отредактировано: D_KEY - 03.07.14, 10:13

Цитата MyNameIsIgor @ 02.07.14, 15:10

Просто зацепились за эту тему, другие роль ведомого подкинуть не позволяет

Вот, после поверхностного знакомства с libcppa вырисовалось

Цитата eao197

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

Вот, кстати, откуда это?

Сообщение отредактировано: MyNameIsIgor - 03.07.14, 13:17

Цитата MyNameIsIgor @ 03.07.14, 13:16

Вот, кстати, откуда это?

Сначала из исходников. Полез посмотреть, как shutdown тамошний устроен.
Потом следы в PDF-ке нашлись, там расписано, как они self реализуют.

Цитата eao197 @ 03.07.14, 13:18

Сначала из исходников. Полез посмотреть, как shutdown тамошний устроен.
Потом следы в PDF-ке нашлись, там расписано, как они self реализуют.

В исходниках не видел. Но по pdf мне не очевидно, что при двух рантаймах случится что-то страшное.

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

Цитата MyNameIsIgor @ 03.07.14, 19:09

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

Ну а какой смысл отправителю pop-а ждать в этом случае? И сколько он будет ждать?
Кроме того, допустим идет большой поток pop-ов к пустому стеку, они не выбрасываются, а скапливаются в очереди. Очередь растет, по сути, происходит утечка ресурсов.