Pull to refresh
7
0
Send message
Я понял, в чем недопонимание :)
Действительно, с точки зрения ООП событие выстреливает, запускается его обработчик и все. Тут не так. Эти события остаются активными, пока не изменится содержимое соответствующей переменной. Для программиста это больше состояние, чем событие
В рамках ситуационной парадигмы, мы навешиваем на все эти переменные определенные события и объединяем их в ситуацию. Именно эту конкретную ситуацию. И тогда, в определенный момент запуститься ее обработчик, который будет смотреть «есть ли у меня козырь?»
Они вроде и сами по себе, но у нас в голове это одна сущность.
С примером не проблема. Дело в том что все вокруг работает по этому принципу.
Рассмотрим ситуацию, когда игрока учат играть в карты и говорят ему: «В игре „Дурак“, когда противник походил мастью, которой у тебя нет, ты должен бить козырем» Это целая сложная ситуация, которая внутри машины будет распределена на несколько переменных и их состояний. Так, например понадобится переменная, указывающая что система вовлечена в игровой процесс, следующая переменная будет содержать вид игры — карточный, следующая будет содержать название игры — «в дурака», следующая будет содержать номер игрока который последним совершил ход, следующая будет содержать масть карты, которая остается не побитой…
Они как бы более понятны для человека. Набор событий (если упаковать их в ситуацию) можно рассмотривать как одну неделимую сущность, которой проще оперировать в уме.
Пока трудно сказать. Возможно введением возможности объединения их в структуры, а также при объявлении указывать глобальная, или локальная для процедуры.
Почему, понимаю. Инкапсуляции нет. Но это не значит, что проблема нерешаема совсем.
Проблема с глобальной видимостью есть. Надо будет думать, что с ней делать.
Событий и ситуаций действительно будет очень много. Но к ним можно получать доступ ассоциативно. Т.е. перед изменением ситуации ее нужно будет выбрать, указав условия ее срабатывания. На первый взгляд это может показаться минусом, но это не так.
Это первая статья, далее я хотел бы объединить этот подход с некоторым другим, что может позволить (в теории) не смотреть в код, а объяснять машине что и когда делать. А именно к описанному ситуационно-ориентированному подходу лучше относиться не как к замене ООП, а как к возможной альтернативе для узкого круга задач (предположительно в интеллектуальных системах).
Действительно, для задач сравнения длинных строк такая реализация не подойдет. Но если взять например переводчик, который должен перевести предложение, то значениями переменных могут быть токены (слова). Допустим для каждой части предложения (главный глагол, актор, актант и все их валентности) будет предусмотрена своя переменная, то их будет не так и много.
Не знаком с такой, посмотрю.
Какой именно?

Этот: Я про момент работы с кодом (т.е., разработку), а не рантайм.

Как, имея под курсором переменную, узнать, какой обработчик(-и) будет вызван, когда значение этой переменной изменится с 2 на 3?

По ключу, состоящему из имени переменной + ее значения (это предварительно) находим соответствующее событие для данной переменной и ее значения 3. Т.е. ключ такой 'имя_переменной=3'. По идентификатору события просматриваем все ситуации, к которым оно привязано.
Хороший вопрос. В статье я действительно это не описал, чтобы не усложнять.
Ситуация это обертка для одного или нескольких событий. Одно событие только на одну переменную. Типов событий два:
1. На изменение значения переменной
2. На конкретное значение переменной.
Такой пример:
Есть переменные X=0, Y=0, Z=0. Создаем: событие E1 для X=2, событие E2 для Y=3, событие E3 для изменения значения переменной Z. Создаем ситуацию S1, которая объединяет в себе все три события E1, E2 и E3.
Теперь, в момент выполнения программы, переменной Y присваиваем значение 3. Срабатывает событие E2, но поскольку оно задействовано в ситуации S1, то в данных ситуации делается пометка, что E2 активировалось.
Далее присваиваем переменной X значение 2. Срабатывает событие E1 и делается пометка в S1. Но сама ситуация S1 пока не сработала, т.к. не активировалось событие E3
Изменение значения переменной Z с нулевого на любое другое вызовет активацию события E3, что в свою очередь уже активирует ситуацию S1 и вызовет ее обработчик.
По поводу Вашего вопроса: в каждом событии указано для какой переменной оно создано, а в каждой ситуации указано какие события в ней задействованы.
В момент первоначальной загрузки обработчика в память. Можно анализировать его код и выставить приоритеты всем обработчикам. Но работоспособность такого подхода еще предстоит доказать.
12 ...
8

Information

Rating
Does not participate
Registered
Activity